Re: Introduce XID age based replication slot invalidation

Hi,

On Fri, Aug 21, 2026 at 03:05:00PM -0700, Bharath Rupireddy wrote:
> Please find the attached v14 patches. 0003 now adds support for
> invalidating XID-aged synced replication slots on standbys.

Thanks for the new version!

I have a few comments:

=== 1

+static inline bool
+CanInvalidateXidAgedSlot(ReplicationSlot *s)
+{
+ return (max_slot_xid_age != 0 &&
+ (TransactionIdIsValid(s->data.xmin) ||
+ TransactionIdIsValid(s->data.catalog_xmin)) &&
+ !(RecoveryInProgress() && s->data.synced));
+}

AFAICS this can also invalidate the reserved pg_conflict_detection slot. The
checkpoint terminates its logical replication launcher, but the restarted
launcher reacquires the invalid slot while subscriptions and workers still
consider conflict information retention active.

I wonder if invalidating this slot should also transition the affected subscriptions
out of conflict information retention, same as stop_conflict_info_retention() is
doing?

Worth adding a test combining retain_dead_tuples with max_slot_xid_age?

=== 2

+ if (TransactionIdPrecedes(oldest_xmin, xid_limit))
+ return InvalidateObsoleteReplicationSlots(RS_INVAL_XID_AGE,
+ 0, InvalidOid,
+ InvalidTransactionId,
+ xid_limit,
+ true, slot_catalog_xmin_relevant);

The previous check:

+ slot_holds_oldest_xmin =
+ (TransactionIdIsValid(slot_xmin) &&
+ TransactionIdEquals(oldest_xmin, slot_xmin)) ||
+ (slot_catalog_xmin_relevant &&
+ TransactionIdIsValid(slot_catalog_xmin) &&
+ TransactionIdEquals(oldest_xmin, slot_catalog_xmin));

proves that a slot holds OldestXmin, but InvalidateObsoleteReplicationSlots()
then invalidates every inactive slot older than xid_limit.

For example, suppose slot A is the oldest horizon, a running transaction is next,
and slot B is newer than that transaction. Both slots exceed max_slot_xid_age.

The function invalidates A and B, although invalidating B cannot advance the
current vacuum cutoff.

I wonder if vacuum should invalidate only the slot or slots holding the current
cutoff, recompute it, and repeat, while doing so advances the cutoff?

=== 3

+ from pruning dead catalog rows and freezing XIDs. Invalidating such a
+ slot on the standby advances the <literal>catalog_xmin</literal> held by
+ the primary's physical slot, letting vacuum there proceed.

This does not seem guaranteed with wal_receiver_status_interval = 0.

And I just realized that this is a pre existing behavior: removing a synced slot
or ordinary logical slot with wal_receiver_status_interval = 0 leaves the old
catalog_xmin on the primary physical slot.

I wonder if removing or invalidating a logical slot on a standby should request
immediate hot standby feedback, or if logical slots on standbys should require
wal_receiver_status_interval > 0 or if we should document the side effects of
setting it to zero? That's probably worth a dedicated thread though.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com