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 20210611020013.phhxgc5u3palfe76@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 18:49:50 -0700, Peter Geoghegan wrote:
> ISTM that it would be much more useful to focus on adding an assertion
> (or maybe even a "can't happen" error) that fails when the DEAD/goto
> path is reached with a tuple whose xmin wasn't aborted. If that was in
> place then we would have caught the bug in
> GetOldestNonRemovableTransactionId() far sooner. That might actually
> catch other bugs in the future.

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).

Greetings,

Andres Freund



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

Предыдущее
От: "tsunakawa.takay@fujitsu.com"
Дата:
Сообщение: RE: Transactions involving multiple postgres foreign servers, take 2
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic