Hi Sami, Thanks for the feedback.
On Thursday, September 17th, 2026 at 7:00 PM, Sami Imseih <[email protected]> wrote: > The need for this comment seems like a sign that this logic is happening at > the wrong level. Master already tests those two flags in ComputeXidHorizons() and GetSnapshotData(). The tree has dozens of comments that say "keep in sync". They mark dependencies, not misplaced logic. v7 replaces the test you quoted with one macro used at all three sites. One keep-in-sync comment remains where ComputeXidHorizons() applies the slot xmins. > I think the underlying function should expose the effective > horizons directly from ComputeXidHorizons(), along with enough information to > identify their sources. > > horizon | datid | xmin | pids | slot_names | gids ComputeXidHorizons() computes the data and catalog horizons for MyDatabaseId only, so a view built on it shows one database per connection. It sees slots as two aggregate xmins and prepared transactions as PGPROCs with pid 0, so it has no slot names or gids. The slot array and the two-phase state hold the slot names and gids, under their own locks, and the patch reads them there. > The view contains the raw information needed to answer these questions, but > leaves the DBA to reconstruct the effective horizons in SQL. A query over the patch's rows produces the summary. No query turns the summary back into the rows. Andres asked for "a view showing all the sources of the horizon being held back" [1]. The view shows every source and the gaps between them, which tell the user how far the horizons could advance. > Would it make sense to drive the view from ComputeXidHorizons() and add the > source attribution on top of those results? Do you mean calling ComputeXidHorizons() for the values and finding the sources in a second pass, or changing ComputeXidHorizons() to record them? [1] https://wiki.postgresql.org/wiki/User:Andresfreund/Desired_Changes -- Scott Ray
signature.asc
Description: OpenPGP digital signature
