Hi Surya, Thanks for the second review.
On Monday, August 24th, 2026 at 9:21 PM, surya poondla <[email protected]> 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
v6-0001-Add-pg_xmin_horizon-view-showing-per-input-horizo.patch
Description: Binary data
signature.asc
Description: OpenPGP digital signature
