Re: Introduce XID age based replication slot invalidation

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Masahiko Sawada <[email protected]>
To: Bharath Rupireddy <[email protected]>
Cc: SATYANARAYANA NARLAPURAM <[email protected]>
Cc: Hayato Kuroda (Fujitsu) <[email protected]>
Cc: John H <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Introduce XID age based replication slot invalidation
Date: Mon, 23 Mar 2026 16:36:07 -0700
Message-ID: <CAD21AoATM=Un8ejnbcDQ7q+CaCoxpkA7Ln9bacvQEoymqvjPug@mail.gmail.com> (raw)
In-Reply-To: <CALj2ACX_o+dKeAaK76mpAtG646UnDHpGUWziUkCvicVz8mz6=A@mail.gmail.com>
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>

Hi,

On Mon, Mar 23, 2026 at 9:00 AM Bharath Rupireddy
<[email protected]> wrote:
>
> Hi,
>
> On Fri, Mar 20, 2026 at 11:29 PM SATYANARAYANA NARLAPURAM
> <[email protected]> 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 required 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 <=
> 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

view thread (31+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Introduce XID age based replication slot invalidation
  In-Reply-To: <CAD21AoATM=Un8ejnbcDQ7q+CaCoxpkA7Ln9bacvQEoymqvjPug@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox