Hi, On 2026-10-04 17:30:00 -0700, Bharath Rupireddy wrote: > While working on XID age based slot invalidation [1] and reviewing the > pg_xmin_horizon patch [2], I realized that a logical replication slot > can hold back VACUUM on user tables while its xmin is shown as NULL in > pg_replication_slots. The documentation describes xmin as the oldest > transaction that the slot needs the database to retain, so the view > doesn't match the documentation in this case. > > There are two cases where this happens. > > 1/ When creating a logical slot with an exported or used snapshot, the > slot holds back the data xmin through its in-memory effective xmin > alone, never the one saved to disk and shown in the view. The slot > creation waits for the transactions with an assigned XID that are > running when it starts, so a long running or prepared transaction can > keep a slot in this state for a long time [3]. Table synchronization > workers in logical replication create their slots this way too, though > they hold the state only for the slot creation.
That seems like a bogus argument to me. Why don't we also include any other xids in the whole system then, given that we wait for those xids? I strongly am against making it impossible to understand what values the slot actually contains. Changing what value is shows without any indication of that seems like a terrible idea to me. If you want to argue for showing more columns in pg_stat_replication slots, maybe, maybe, but faking up values: no. Greetings, Andres Freund
