Horton

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2021-06-09T02:42:09Z
Lists: pgsql-hackers 
On Tue, Jun 08, 2021 at 05:47:28PM -0700, Peter Geoghegan wrote:
> I don't have time to try this out myself today, but offhand I'm pretty
> confident that this is sufficient to reproduce the underlying bug
> itself. And if that's true then I guess it can't have anything to do
> with the pg_upgrade/pg_resetwal issue Tom just referenced, despite the
> apparent similarity.

Agreed.  It took me a couple of minutes to get autovacuum to run in an
infinite loop with a standalone instance.  Nice catch, Justin!
--
Michael

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.