| 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
| 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 |