Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
От | Andres Freund |
---|---|
Тема | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic |
Дата | |
Msg-id | 20210611023816.fpc7v2wi3tclrsbh@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
|
Список | pgsql-hackers |
Hi, On 2021-06-10 19:15:59 -0700, Peter Geoghegan wrote: > On Thu, Jun 10, 2021 at 7:00 PM Andres Freund <andres@anarazel.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. 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. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: