Re: Persist slot invalidations before publishing them

Hi,

On Fri, Aug 28, 2026 at 03:59:32PM +0530, Amit Kapila wrote:
> On Wed, Aug 26, 2026 at 7:19 PM Bertrand Drouvot
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> >
> > while reviewing [1], I hit an issue due to the fact that an inactive replication
> > slot is marked invalid in shared memory before its new state is persisted.
> >
> > 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.
> >
> > The same issue exists in synchronize_one_slot(): it copies the invalidation from
> > the remote slot into the local synchronized slot before saving it. In that case,
> > a save error also prevents a direct retry because the next synchronization sees
> > the local slot as already invalid and skips it.
> >
>
> Won't the drop_local_obsolete_slots() drop the locally invalidated
> slot before trying to synchronize the remote_slot in the next slot?
>

It would be if the remote slot were valid and only the local slot invalidated.

Here both are invalidated, so locally_invalidated is false and local_sync_slot_required()
returns true. Thus, drop_local_obsolete_slots() keeps the local slot.
synchronize_one_slot() then sees it already invalidated and skips the save.

The test added by 0002 is meant to cover this. I noticed that v1 restarts
before synchronizing again though, so I changed it in v2 to retry before the
immediate restart and make this case explicit.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com