Horton

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
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>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2021-06-11T03:16:40Z
Lists: pgsql-hackers 
On Thu, Jun 10, 2021 at 7:38 PM Andres Freund <andres@anarazel.de> wrote:
> Well, I'd like to add assertions ensuring the retry path is only entered
> when correct - but I feel hesitant about doing so when I can't exercise
> that path reliably in at least some of the situations.

I originally tested the lazy_scan_prune() goto in the obvious way: by
adding a pg_usleep() just after its heap_page_prune() call. I'm not
too worried about the restart corrupting state or something, because
the state is pretty trivial. In any case the infrastructure to
exercise the goto inside the tests doesn't exist yet -- I don't see
any way around that on HEAD.

OTOH I *am* concerned about the goto doing the wrong thing due to bugs
in distant code. I cannot imagine any possible downside to at least
asserting HeapTupleHeaderXminInvalid() against the "concurrently
inserted then abort" tuple. That simple measure would have been enough
to at least catch this particular bug far sooner.

-- 
Peter Geoghegan

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.