Hi, On Tue, Oct 6, 2026 at 1:15 PM Andres Freund <[email protected]> wrote: > > > 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. > > 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?
Fair enough. The pg_xmin_horizon thread intends to report all the vacuum blockers. My intention was to close the gap just for a given replication slot when its xmins say null but it's silently holding resources. > 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. Thinking from the back-patching perspective made me come up with the overload idea, and I understand my thinking was bad here. That said, by having more columns, isn't the pg_replication_slots view just getting more bloated, since most of the time the effective xmins are closer to the xmins (effective xmin <= xmin)? Maybe that's okay for HEAD? And it could be explained in the docs to clarify. Thoughts? -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
