Re: Persist slot invalidations before publishing them

Hello,

At Wed, 26 Aug 2026 13:49:24 +0000, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote in
> If ReplicationSlotSave() errors before replacing the state file, the slot is
> invalid in shared memory but still valid on disk. That sounds problematic as the
> resource horizon computations could stop accounting for the slot, remove required
> WAL or rows, and then an immediate restart would restore the old valid slot image.

I've spent some time looking through the related discussions and
patches, and I think I now have a better understanding of the
problem. I have a question about the persistence mechanism.

For the InvalidatePossiblyObsoleteSlot() case, at least for
RS_INVAL_XID_AGE, if the server crashes after the slot is invalidated
but before the invalidation is persisted, it seems that the restored
slot would still satisfy the same XID-age condition and would
eventually be invalidated again by vacuum or checkpoint. Is the main
reason for making the invalidation durable here that we don't want to
leave the slot valid until that next opportunity?

If so, I'm a little uncomfortable with persisting a modified copy of
the normal slot state before that state has actually been published in
shared memory. It seems to make the state transition somewhat harder
to follow, since the slot state file no longer necessarily represents
the current slot state.

Would it be simpler to persist the invalidation separately? For
example, we could write the invalidation cause to a small file such as
pg_replslot/<slotname>/invalidated and make it durable before
publishing the invalidation in shared memory. On restart, that file
would cause the slot to be restored as invalidated with the recorded
cause. This would keep the normal slot state file as a representation
of the actual slot state, and would also naturally avoid the race with
concurrent slot saves.

Regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center