Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Дата
Msg-id CAH2-Wzm7Ha_fL+iyuNOa3gFBZZr5gnb7PWdxxoQjOW_r1FOc-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic  (Andres Freund <andres@anarazel.de>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Duplicate history file?
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Multi-Column List Partitioning