Re: Persist slot invalidations before publishing them

Hi,

On Wed, Sep 23, 2026 at 12:00:39PM +0530, shveta malik wrote:
> On Wed, Sep 23, 2026 at 11:37 AM Bertrand Drouvot
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> >
> > Another possibility would be to make ReplicationSlotPersistInvalidation() always
> > leave the caller acquired I/O lock held. Slotsync could then release that specific
> > lock in a PG_CATCH() block, something like:
>
> Yes, I agree. I find this approach much better for 2 reasons:
>
> 1) The caller has better control over the lock, which makes sense
> since it is the one acquiring it.
> 2) It makes the code much more understandable. Earlier, it took me a
> while to figure out exactly where the io_in_progress_lock was getting
> released, especially looking at the slotsync patch where it was
> acquired right before calling ReplicationSlotPersistInvalidation().
>
> > "
> > PG_CATCH();
> > {
> > HOLD_INTERRUPTS();
> > LWLockRelease(&slot->io_in_progress_lock);
> > PG_RE_THROW();
> > }
> > PG_END_TRY();
> >
> > LWLockRelease(&slot->io_in_progress_lock);
> > "
> >
> > This would avoid both LWLockReleaseAll() and using LWLockHeldByMe() for normal
> > control flow. Does that sound preferable?
>
> Yes.

Thanks! Done that way in v4 attached.

Regards,

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