Hello, At Wed, 26 Aug 2026 13:49:24 +0000, Bertrand Drouvot <[email protected]> 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
