Re: Introduce XID age based replication slot invalidation

Hi,

On Tue, Sep 01, 2026 at 04:13:10AM +0000, Zhijie Hou (Fujitsu) wrote:
> On Tuesday, September 1, 2026 11:20 AM Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> > On Friday, August 28, 2026 8:17 AM Bharath Rupireddy
> > <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> >
> > I am wondering whether we could choose a simpler way. That is, change the
> > launcher to not acquire the slot when it's invalidated. This way the user has
> > the option to drop the slot and disable retain_dead_tuples, or just drop the
> > slot and the launcher will later re-create it if retain_dead_tuples is still
> > enabled.
>
> Note that this might require changes to allow users to drop reserved slots (the
> pg_conflict_detection slot is reserved by design, so users cannot acquire it).
> So this might not be practical.
>
> If we want to avoid this change, a simpler approach is to let the launcher
> auto-drop the invalidated slot, recreate it, and log a WARNING.

IIUC, recreating the slot alone could make the launcher try to move its xmin
backwards, as running workers may still have an older oldest_nonremovable_xid.

Stopping all the workers would avoid that, but looks a bit too disruptive if only
one disabled subscription or one without a running apply worker prevented the
pg_conflict_detection slot from advancing.

I wonder if we could combine the worker side check with a launcher side check,
as Nisha suggested, and back off only the subscriptions holding the slot back?
That would let the other workers continue normally.

Regards,

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