| 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 02:15:59 |
| Message-ID: | CAH2-WzmN1SquPR=7Rx0-o7areXVNSsfz3pCGeyzcv6s4cB9QcQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 10, 2021 at 7:00 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I'm not convinced - right now we don't exercise this path in tests at
> all. More assertions won't change that - stuff that can be triggered in
> production-ish loads doesn't help during development. I do think that
> that makes it far too easy to have state management bugs (e.g. a wrong
> pincount in retry cases or such).
The code in lazy_scan_prune() led to our detecting this bug (albeit in
a fairly nasty way). The problematic VACUUM operations never actually
exercised the goto as originally designed, for the purpose it was
intended for. Perhaps we should add test coverage for the intended
behavior too, but that doesn't seem particularly relevant right now.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2021-06-11 02:25:51 | Re: Duplicate history file? |
| Previous Message | Jeff Davis | 2021-06-11 02:14:32 | Re: Patch: Range Merge Join |