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
