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) > <[email protected]> wrote: > > On Friday, August 28, 2026 8:17 AM Bharath Rupireddy > > <[email protected]> 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
