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

From: Scott Ray <scott(at)scottray(dot)io>
To: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, surya poondla <suryapoondla4(at)gmail(dot)com>
Subject: Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon
Date: 2026-09-27 21:06:48
Message-ID: 5x8VRERZxSIJ7thPBHMfEnE01ak_VVoMlCewFS2mhRB7q8Iy_3LP7qCtI_KVjd_bCMZ8_HDBmlabKuADPaic1KDJHAJMl3mSCaT4DgumPdE=@scottray.io
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Sami,

Thanks for the feedback.

On Thursday, September 17th, 2026 at 7:00 PM, Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Scott Ray 2026-09-27 21:12:01 Re: Recovery conflict resolution misses backends that import snapshots
Previous Message Scott Ray 2026-09-27 20:58:56 Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon