Horton

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-hackers@lists.postgresql.org, Matthias van de Meent <boekewurm+postgres@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2021-06-08T16:06:02Z
Lists: pgsql-hackers 
On 2021-Jun-06, Justin Pryzby wrote:

> However, I also found an autovacuum chewing 100% CPU, and it appears the
> problem is actually because autovacuum has locked a page of pg-statistic, and
> every other process then gets stuck waiting in the planner.  I checked a few
> and found these:

> [...]

Hmm ... I wonder if this could be related to commits d9d076222f5b,
c98763bf51bf, etc.  I don't have any connecting thoughts other than the
tuple visibility code being involved.  Do you see any procs with the
PROC_IN_SAFE_IC flag set?

-- 
Álvaro Herrera                            39°49'30"S 73°17'W

Commits

  1. Deduplicate choice of horizon for a relation procarray.c.

  2. Use correct horizon when vacuuming catalog relations.

  3. Truncate line pointer array during VACUUM.

  4. Remove tupgone special case from vacuumlazy.c.

  5. Refactor lazy_scan_heap() loop.

  6. snapshot scalability: Don't compute global horizons while building snapshots.