Re: Checkpoint replication slots later

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Hüseyin Demir <huseyin(dot)d3r(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Ants Aasma <ants(at)cybertec(dot)at>
Subject: Re: Checkpoint replication slots later
Date: 2026-07-10 14:55:49
Message-ID: CAHGQGwEnh2AnOZz+_tfUR9j=xb6FVe=hbHmd0pYPSky5AQ-_Vg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, May 17, 2026 at 1:38 AM Hüseyin Demir <huseyin(dot)d3r(at)gmail(dot)com> wrote:
>
> Hi Ant,
>
> Good idea.

+1.

CheckPointSnapBuild() and CheckPointLogicalRewriteHeap() call
ReplicationSlotsComputeLogicalRestartLSN(), which seems to use
last_saved_restart_lsn for persistent logical slots. Since
last_saved_restart_lsn is updated by CheckPointReplicationSlots(),
if those functions run before it, their cleanup decisions are still
based on the restart_lsn saved at the previous checkpoint.

So, isn't it better to move them after CheckPointReplicationSlots()
as well, so that logical snapshot and rewrite mapping cleanup can use
the newly saved restart_lsn?

Of course, we'd first need to confirm that doing so is safe, though.

Regards,

--
Fujii Masao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Lucas Jeffrey 2026-07-10 15:26:17 Re: [PATCH] Fix segmentation fault caused by reentrancy in RI_Fkey_cascade_del (ri_triggers.c)
Previous Message Andres Freund 2026-07-10 14:49:19 Re: Missing FSM Update when Updating VM On-access