Re: [PATCH] Allow to specify restart_lsn inpg_create_physical_replication_slot() - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH] Allow to specify restart_lsn inpg_create_physical_replication_slot()
Date
Msg-id 20200623011843.GE50978@paquier.xyz
Whole thread Raw
In response to Re: [PATCH] Allow to specify restart_lsn inpg_create_physical_replication_slot()  (Alexey Kondratov <a.kondratov@postgrespro.ru>)
Responses Re: [PATCH] Allow to specify restart_lsn inpg_create_physical_replication_slot()  (Alexey Kondratov <a.kondratov@postgrespro.ru>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: min_safe_lsn column in pg_replication_slots view
Next
From: Thomas Munro
Date:
Subject: Move syncscan.c?