Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

From: "Andres Freund" <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Date: 2021-06-06 18:01:54
Message-ID: 63dae6b5-3266-4522-a4b2-bd7908a5aedc@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sun, Jun 6, 2021, at 10:59, Tom Lane wrote:
> Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> writes:
> > On Sun, 6 Jun 2021 at 18:35, Justin Pryzby <pryzby(at)telsasoft(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-06-06 18:43:11 Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Previous Message Peter Geoghegan 2021-06-06 18:00:38 Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic