On Mon, Jun 22, 2020 at 08:18:58PM +0300, Alexey Kondratov wrote: > I wonder how it could be used via the replication protocol, but probably > this option should be added there as well for consistency.
Mostly the same code path is taken by the SQL function and the replication command, so adding a new option to both when adding a new option makes sense to me for consistency. The SQL functions are actually easier to use when it comes to tests, as there is no need to worry about COPY_BOTH not supported in psql. > Things get worse when we allow specifying an older LSN, since it has a > higher chances to be at the horizon of deletion by checkpointer. Anyway, if > I get it correctly, with a current patch slot will be created successfully, > but will be obsolete and should be invalidated by the next checkpoint. Is that a behavior acceptable for the end user? For example, a physical slot that is created to immediately reserve WAL may get invalidated, causing it to actually not keep WAL around contrary to what the user has wanted the command to do. -- Michael
signature.asc
Description: PGP signature
