Horton

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Masahiko Sawada <sawada.mshk@gmail.com>, Andres Freund <andres@anarazel.de>
Date: 2021-06-09T00:11:20Z
Lists: pgsql-hackers 
Peter Geoghegan <pg@bowt.ie> writes:
> On Tue, Jun 8, 2021 at 5:27 AM Matthias van de Meent
>>> (gdb) p GlobalVisCatalogRels
>>> $57 = {definitely_needed = {value = 926025113}, maybe_needed = {value = 926025112}}

>> This maybe_needed is older than the OldestXmin, which indeed gives us
>> this problematic behaviour:

> Good catch.

I wonder if this is a variant of the problem shown at

https://www.postgresql.org/message-id/2591376.1621196582%40sss.pgh.pa.us

where maybe_needed was visibly quite insane.  This value is
less visibly insane, but it's still wrong.  It might be
interesting to try running this test case with the extra
assertions I proposed there, to try to narrow down where
it's going off the rails.

			regards, tom lane

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.