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  (Peter Geoghegan <pg@bowt.ie>)
Список 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 по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Duplicate history file?
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Duplicate history file?