Thread

1. Checkpoint replication slots later

   Ants Aasma <ants.aasma@cybertec.at> — 2026-05-07T10:28:07Z

   Hi,
   
   Right now replication slots are synced close to the beginning of
   CheckpointGuts(). Importantly, before CheckPointBuffers() which for spread
   checkpoints might take most of checkpoint_timeout to complete. This is a
   problem because this function calculates how much WAL to keep around in
   ReplicationSlotsComputeRequiredLSN(). By the time RemoveOldXlogFiles() gets
   called this information might be quite stale and we hold onto many WAL
   files unnecessarily until the next checkpoint cycle.
   
   As far as I could tell there is no reason for this to happen early, so in
   the attached patched I just moved it down closer to the end.
   
   Regards,
   Ants Aasma
   

2. Re: Checkpoint replication slots later

   Hüseyin Demir <huseyin.d3r@gmail.com> — 2026-05-16T16:37:31Z

   Hi Ant, 
   
   Good idea. Moving CheckPointReplicationSlots() to the end of CheckPointGuts() means we can see more fresher restart_lsn. It's especially valuable for spread checkpoints as you described. 
   
   While reading the code for this, I noticed that the ReplicationSlot.last_saved_restart_lsn is completely invisible to operators today.
   
   pg_replication_slots.restart_lsn exposes slot->data.restart_lsn, the current in-memory value, but WAL removal for persistent slots is gated on last_saved_restart_lsn (the value last
   durably written to disk at checkpoint), not restart_lsn. See ReplicationSlotsComputeRequiredLSN() at slot.c:1346–1352:
   
   Your patch makes the it more current at cleanup time, which helps. But between checkpoints the gap can still be wide. Should we also expose last_saved_restart_lsn since it's already available and can be exposed. ? Otherwise, the current approach LGTM.