Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Дата
Msg-id 1833145.1623376824@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> 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.

Sounds like a good idea.  If we expect that path to be taken only
rarely, then a test-and-elog would be worth its keep.  Otherwise
maybe it should just be an Assert.

            regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Следующее
От: "osumi.takamichi@fujitsu.com"
Дата:
Сообщение: timing sensitive failure of test_decoding RT that exists in PG9.6