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

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