Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Matthias van de Meent <boekewurm+postgres@gmail.com>
From: Matthias van de Meent <boekewurm+postgres@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>,
Andres Freund <andres@anarazel.de>, 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-06-10T17:29:29Z
Lists: pgsql-hackers
On Thu, 10 Jun 2021 at 19:07, Peter Geoghegan <pg@bowt.ie> wrote: > > On Thu, Jun 10, 2021 at 9:57 AM Matthias van de Meent > <boekewurm+postgres@gmail.com> wrote: > > > By "matches what we expect", I meant "involves a just-aborted > > > transaction". We could defensively verify that the inserting > > > transaction concurrently aborted at the point of retrying/calling > > > heap_page_prune() a second time. If there is no aborted transaction > > > involved (as was the case with this bug), then we can be confident > > > that something is seriously broken. > > > > I believe there are more cases than only the rolled back case, but > > checking for those cases would potentially help, yes. > > Why do you believe that there are other cases? > > I'm not aware of any case that causes lazy_scan_prune() to retry using > the goto, other than the aborted transaction case I described > (excluding the bug that you diagnosed, which was of course never > supposed to happen). If it really is possible to observe a retry for > any other reason then I'd very much like to know all the details - it > might well signal a distinct bug of the same general variety. I see one exit for HEAPTUPLE_DEAD on a potentially recently committed xvac (?), and we might also check against recently committed transactions if xmin == xmax, although apparently that is not implemented right now. With regards, Matthias van de Meent
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