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
|
Список | 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 по дате отправления: