| 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
| 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 |