Horton

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: "Andres Freund" <andres@anarazel.de>
To: pgsql-hackers@lists.postgresql.org
Date: 2021-06-06T18:01:54Z
Lists: pgsql-hackers 
Hi, 

On Sun, Jun 6, 2021, at 10:59, Tom Lane wrote:
> Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
> > On Sun, 6 Jun 2021 at 18:35, Justin Pryzby <pryzby@telsasoft.com> 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:
> 
> > My suspicion is that for some tuple on that page
> > HeapTupleSatisfiesVacuum() returns HEAPTUPLE_DEAD for a tuple that it
> > thinks should have been cleaned up by heap_page_prune, but isn't. This
> > would result in an infinite loop in lazy_scan_prune where the
> > condition on vacuumlazy.c:1800 will always be true, but the retry will
> > not do the job it's expected to do.
> 
> Since Justin's got a debugger on the process already, it probably
> wouldn't be too hard to confirm or disprove that theory by stepping
> through the code.

If that turns out to be the issue, it'd be good to check what prevents the tuple from being considered fully dead, by stepping through the visibility test...

Andres

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.