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

From: surya poondla <suryapoondla4(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Scott Ray <scott(at)scottray(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon
Date: 2026-09-17 20:14:03
Message-ID: CAOVWO5rn2MNrMXyt4ufZ7G9oqQ1BX3eoYULiMtsLM7obCevdfw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Bharath,

Thanks for the measurements. I raised the single-pass point earlier but
without numbers, so it's good to see it quantified.

Regarding your point 22, pgstat_get_beentry_by_proc_number() calls
pgstat_get_local_beentry_by_proc_number(), which calls
pgstat_read_current_status() and then searches localBackendStatusTable,
so it reads the cached per-transaction snapshot rather than
BackendStatusArray.
Two consequences: the xact_start value would again come from a snapshot
that can predate the procarray pass by an arbitrary
amount, which is what I asked Scott to fix and why the new helper reads the
array directly. And building that snapshot is the loop that takes
ProcArrayLock once per active backend, which is the cost your point 18
measures.

The change-count retry does happen, but only while the snapshot is being
built. After that the caller is reading a local copy, so it doesn't buy
freshness.

Regards,
Surya Poondla

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Rodríguez 2026-09-17 20:25:35 Re: Unexpected reindex when altering column types for partitioned tables
Previous Message Bharath Rupireddy 2026-09-17 19:06:00 Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start