Re: Introduce XID age based replication slot invalidation

Hi,

On Tue, Sep 22, 2026 at 2:19 AM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> 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