Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon

Hi Surya,

Thanks for the second review.

On Monday, August 24th, 2026 at 9:21 PM, surya poondla <suryapoondla4(at)gmail(dot)com> wrote:
> Yes, the slots' effective xmins, and the vacuum/logical-decoding proc
> flags are the parts of the view that aren't reconstructible, and I
> think both should be emitted from the existing views regardless.

I responded to these ideas in my reply to Bharath here:
https://postgr.es/m/_v-TXkivtfKDQiGSqD554fcsG2mFRvO20t4g2Msycyd-ruyWwO0NrIetxDISwd-o1vWi3zbwht90cnZWeUAa4KlM6kDFUylyNik9irEIap0=@scottray.io

> This is specific to backend rows. Slots and prepared transactions are
> already read live, pg_get_replication_slots() reads
> shared memory directly and pg_prepared_xact() reads TwoPhaseState, so for
> those kinds an SQL join would be ok.
> [...]
> I'd keep C code only for the backend rows, where the single-pass
> read buys something SQL can't.

Implementing the horizon logic - not just the gather - in C instead
of SQL buys us three things:

1. It keeps the scope of the feature small, because C can access
every horizon input without adding columns to other views. In the
future, the SRF can read KnownAssignedXids and any new horizon inputs
without new SQL-callable functions.

2. It publishes the answer to "how does each source affect the
xmin horizons?" without exposing intermediate steps. I explained
in my reply to Bharath why we shouldn't add raw flags like
PROC_IN_LOGICAL_DECODING as columns to existing views. I'll explain
below why we shouldn't add derived booleans either.

3. Mirroring the horizon logic in the same language as the original
code eases the tasks of reviewing the new code and keeping
the copies synchronized.

> For the proc flags I have no strong preference, maybe a derived boolean,
> like whether this backend's xmin is actually counted toward the horizon.
> That avoids putting internal flag names into a user-visible catalog.

"Whether this backend's xmin is actually counted toward the horizon"
depends on which horizon one picks. For example, a backend in another
database counts toward the shared horizon but not toward the current
database's data or catalog horizons. The view needs per-class
contributions, which pg_get_xmin_horizon() already provides. Delegating
part of the work to pg_stat_activity, which would publish a half answer,
offers only disadvantages compared to v5.

> Lastly, one thing that follows either way: every column the SRF returns
> comes from its single procarray pass, but the view then joins
> pg_stat_activity for xact_start alone, against that cached snapshot rather
> than the pass just taken. So a backend the SRF sees can come back with a
> null xact_start, or a stale one from an earlier transaction of the same
> pid. Better returned from the SRF.

Thanks for pointing this out. The attached v6 applies your suggestion.
pg_get_xmin_horizon()'s header comment documents a race reading the
transaction start, and the new helper's header comment explains why
it omits walsender timestamps.

--
Scott Ray