Hi, On Tue, Sep 22, 2026 at 2:19 AM Bertrand Drouvot <[email protected]> wrote: > > On Fri, Sep 18, 2026 at 10:40:00AM -0700, Bharath Rupireddy wrote: > > > > One approach is to never invalidate the slot, and to honour > > max_slot_xid_age by stopping conflict info retention for whoever is > > holding the slot's xmin back. On the worker side, the existing > > should_stop_conflict_info_retention() stops retention when the > > worker's oldest xid has aged past the age limit, whether or not a > > retention duration is set. On the launcher side, once per cycle, right > > after it tries to advance the xmin as usual, if the xmin has aged past > > the age limit it stops retention by setting subretentionactive to > > false in pg_subscription > > How do you see the launcher updating pg_subscription here? Are you thinking > of a > launcher specific update path? > > > I prefer the first approach, > > +1 on the first approach. It is what I had in mind when suggesting combining > the > worker and launcher checks.
Hm. I realized the launcher doesn’t connect to a specific database. It can read the pg_subscription shared catalog, but it can’t update it, because a catalog update also inserts into the catalog’s indexes, and the index list comes from pg_index, which is database-specific and not accessible there. So I’m thinking of this approach. The launcher checks the slot for XID age, and when the limit is hit it sets a flag in its existing per-subscription shmem (LauncherLastStartTimesEntry) for every subscription still retaining, and lets the apply worker update the catalog. The launcher creates an entry even for the subscriptions whose apply worker is not running, such as disabled ones. When the flag is set, a running apply worker stops through the existing path (stop_conflict_info_retention()), setting subretentionactive to false, and the launcher does not move the slot’s xmin past that worker’s xid until the stop is recorded. For the subscriptions whose apply worker is not running, the launcher stops honoring their retention immediately and their apply worker records the stop when it next starts. Once the xmin is no longer aged, the launcher clears the flag for the subscriptions whose stop is recorded, and retention resumes through the existing path. Until then a worker whose stop is recorded does not resume. This way the slot is never invalidated. For example, with XID age = 100, sub1 enabled and sub2 disabled, both retaining: 1/ The slot's xmin stops advancing at 500, because sub2 has no apply worker. 2/ At XID 600 the xmin is aged, so the launcher flags both. sub1's worker stops retaining and records it. sub2 has no worker, so the launcher stops counting it right away. 3/ Nothing to count, so the launcher clears the slot's xmin and vacuum moves on. The slot stays valid. 4/ The xmin is no longer aged, so the launcher clears sub1's flag. Its worker resumes retaining and the slot's xmin restarts at 600. 5/ sub2 stays flagged. When enabled, its worker records the stop at startup and resumes once it has caught up. Thoughts? -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
