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
