Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>,
Michael Paquier <michael@paquier.xyz>, Justin Pryzby <pryzby@telsasoft.com>,
Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Masahiko Sawada <sawada.mshk@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2021-07-16T23:13:03Z
Lists: pgsql-hackers
On Wed, Jun 16, 2021 at 1:21 PM Peter Geoghegan <pg@bowt.ie> wrote: > Oh yeah, I think that I get it now. Tell me if this sounds right to you: > > It's not so much that HeapTupleSatisfiesVacuum() "disagrees" with > heap_prune_satisfies_vacuum() in a way that actually matters to > VACUUM. While there does seem to be a fairly mundane bug in > GetOldestNonRemovableTransactionId() that really is a matter of > disagreement between the two functions, the fundamental issue is > deeper than that. The fundamental issue is that it's not okay to > assume that the XID horizon won't go backwards. This probably matters > for lots of reasons. The most obvious reason is that in theory it > could cause lazy_scan_prune() to get stuck in about the same way as > Justin reported, with the GetOldestNonRemovableTransactionId() bug. Any update on this, Andres? -- Peter Geoghegan
Commits
-
Deduplicate choice of horizon for a relation procarray.c.
- 3d0a4636aa4c 14.0 landed
- d9d8aa9bb9aa 15.0 landed
-
Use correct horizon when vacuuming catalog relations.
- 5a1e1d83022b 14.0 landed
-
Truncate line pointer array during VACUUM.
- 3c3b8a4b2689 14.0 cited
-
Remove tupgone special case from vacuumlazy.c.
- 8523492d4e34 14.0 cited
-
Refactor lazy_scan_heap() loop.
- 7ab96cf6b312 14.0 cited
-
snapshot scalability: Don't compute global horizons while building snapshots.
- dc7420c2c927 14.0 cited