|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru>|
|Cc:||Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Vyacheslav Makarov <v(dot)makarov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org|
|Subject:||Re: [PATCH] Allow to specify restart_lsn in pg_create_physical_replication_slot()|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|Next Message||Thomas Munro||2020-06-23 01:30:39||Move syncscan.c?|
|Previous Message||Kyotaro Horiguchi||2020-06-23 01:10:37||Re: min_safe_lsn column in pg_replication_slots view|