| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic |
| Date: | 2021-06-11 03:16:40 |
| Message-ID: | CAH2-Wzm7Ha_fL+iyuNOa3gFBZZr5gnb7PWdxxoQjOW_r1FOc-w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 10, 2021 at 7:38 PM Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2021-06-11 03:37:54 | Re: Multi-Column List Partitioning |
| Previous Message | Julien Rouhaud | 2021-06-11 02:48:32 | Re: Duplicate history file? |