Re: Show effective xmin in pg_replication_slots when xmin is not set

Hi,

On Tue, Oct 6, 2026 at 1:15 PM Andres Freund <andres(at)anarazel(dot)de> 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