Incremental Analysis: New Response from Huseyin
Summary
A new participant (Huseyin) responds with approval of the patch but raises a tangential but technically interesting observability concern about ReplicationSlot.last_saved_restart_lsn.
New Technical Point: Exposing last_saved_restart_lsn
Huseyin identifies that WAL removal for persistent slots is gated on last_saved_restart_lsn (the value last durably flushed to disk at checkpoint time), not on restart_lsn (the current in-memory value). The pg_replication_slots view only exposes restart_lsn, meaning operators cannot see which LSN actually governs WAL retention between checkpoints.
This is a separable concern from the patch itself — Aasma's reordering reduces the staleness of last_saved_restart_lsn at checkpoint time, but between checkpoints a gap still exists. Huseyin suggests exposing last_saved_restart_lsn in pg_replication_slots so operators can understand why WAL is being retained beyond what restart_lsn would suggest.
The specific code reference is ReplicationSlotsComputeRequiredLSN() at slot.c:1346–1352, which iterates slots and uses last_saved_restart_lsn (not the live restart_lsn) for the retention decision.
Verdict on the Patch
Huseyin gives an LGTM on the core reordering change. The last_saved_restart_lsn exposure suggestion is framed as a potential follow-up, not a blocker.