Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon - Mailing list pgsql-hackers

From surya poondla
Subject Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon
Date
Msg-id CAOVWO5rn2MNrMXyt4ufZ7G9oqQ1BX3eoYULiMtsLM7obCevdfw@mail.gmail.com
Whole thread
In response to Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon
List 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

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start
Next
From: Álvaro Rodríguez
Date:
Subject: Re: Unexpected reindex when altering column types for partitioned tables