MIME-Version: 1.0
References: 
 <CA+-JvFsMHckBMzsu5Ov9HCG3AFbMh056hHy1FiXazBRtZ9pFBg@mail.gmail.com>
 <OSCPR01MB149667506BCFD684FEFDCB919F511A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <CALj2ACUmPbkcj4y4oeXvzUkBejG68QDtrFF7QHDC_qz2vQcTCg@mail.gmail.com>
 <CAHg+QDfnK7tQxsEZox=kOkYfqANmL70mwn0N=eRrJxE1Z+1ygg@mail.gmail.com>
 <CALj2ACX_o+dKeAaK76mpAtG646UnDHpGUWziUkCvicVz8mz6=A@mail.gmail.com>
In-Reply-To: 
 <CALj2ACX_o+dKeAaK76mpAtG646UnDHpGUWziUkCvicVz8mz6=A@mail.gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Mon, 23 Mar 2026 16:36:07 -0700
Message-ID: 
 <CAD21AoATM=Un8ejnbcDQ7q+CaCoxpkA7Ln9bacvQEoymqvjPug@mail.gmail.com>
Subject: Re: Introduce XID age based replication slot invalidation
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
 John H <johnhyvr@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAD21AoATM%3DUn8ejnbcDQ7q%2BCaCoxpkA7Ln9bacvQEoymqvjPug%40mail.gmail.com>
Precedence: bulk

Hi,

On Mon, Mar 23, 2026 at 9:00=E2=80=AFAM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Hi,
>
> On Fri, Mar 20, 2026 at 11:29=E2=80=AFPM SATYANARAYANA NARLAPURAM
> <satyanarlapuram@gmail.com> wrote:
> >
> > Do you think we need different GUCs for catalog_xmin and xmin? If table=
 bloat is a concern (not catalog bloat), then logical slots are not require=
d to invalidate unless the cluster is close to wraparound.
>
> IMO the main purpose of max_slot_xid_age is to prevent XID wraparound.
> For bloat, I still think max_slot_wal_keep_size is the better choice.
>
> Where max_slot_xid_age is really useful is when the vacuum can't
> freeze because a replication slot (physical or logical) is holding
> back the XID horizon and the system is getting close to wraparound.
> Invalidating such a slot clears the way for vacuum. Setting
> max_slot_xid_age above vacuum_failsafe_age allows vacuum to waste
> cycles scanning tables it cannot freeze. Keeping max_slot_xid_age <=3D
> vacuum_failsafe_age (default 1.6B) prevents this by invalidating the
> slot before vacuum effort is wasted.
>
> As far as XID wraparound is concerned, both xmin and catalog_xmin need
> to be treated similarly. Either one can hold back freezing and push
> the system toward wraparound. So I don't think we need separate GUCs
> for xmin and catalog_xmin unless I'm missing something. One GUC
> covering both keeps things simple.

I've studied the discussion on this thread and the patch. I understand
the purpose of this feature and agree that it's useful especially in
cases where orphaned (physical or logical) replication slots prevent
the xmin from advancing and inactive_since based slot invalidation
might not fit.

And +1 for treating both the slot's xmin and catalog_xmin similarly
with the single GUC.

> >> I made the following design choice: try invalidating only once per
> >> vacuum cycle, not per table. While this keeps the cost of checking
> >> (incl. the XidGenLock contention) for invalidation to a minimum when
> >> there are a large number of tables and replication slots, it can be
> >> less effective when individual tables/indexes are large. Invalidating
> >> during checkpoints can help to some extent with the large table/index
> >> cases. But I'm open to thoughts on this.
> >
> > It may not solve the intent when the vacuum cycle is longer, which one =
can expect on a large database particularly when there is heavy bloat.
>
> This design choice boils down to the following: a database instance
> having either 1/ a large number of small tables or 2/ large tables.
> From my experience, I have seen both cases but mostly case 2 (others
> can correct me). In this context, having an XID age based slot
> invalidation check once per relation makes sense. However, I'm open to
> more thoughts here.

ISTM that checking the XID-based slot invalidation per table would be
more bullet-proof and cover many cases. How about checking the
XID-based slot invalidation opportunity only when the OldestXmin is
older than the new GUC? For example, we can do this check in
heap_vacuum_rel() based on the VacuumCutoffs returned by
vacuum_get_cutoffs(). If we invalidate at least one slot for its XID,
we can re-compute the OldestXmin.

Regards,

--
Masahiko Sawada


Amazon Web Services: https://aws.amazon.com