Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum
От | Andres Freund |
---|---|
Тема | Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum |
Дата | |
Msg-id | 20211111010325.hpwxetvktafkyulw@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-bugs |
Hi, On 2021-11-10 13:40:25 -0800, Peter Geoghegan wrote: > On Wed, Nov 10, 2021 at 1:04 PM Peter Geoghegan <pg@bowt.ie> wrote: > > On Wed, Nov 10, 2021 at 11:20 AM Andres Freund <andres@anarazel.de> wrote: > > > The way this definitely breaks - I have been able to reproduce this in > > > isolation - is when one tuple is processed twice by heap_prune_chain(), and > > > the result of HeapTupleSatisfiesVacuum() changes from > > > HEAPTUPLE_DELETE_IN_PROGRESS to DEAD. > > > > I had no idea that that was now possible. I really think that this > > ought to be documented centrally. > > BTW, is it just a coincidence that we have only seen these problems > with pg_class? Or does it have something to do with the specifics of > VISHORIZON_CATALOG/horizons.catalog_oldest_nonremovable, or something > else along those lines? It's the testcase. The test instructions specify autovacuum=off and only pg_class is vacuumed. There are a other hot updates than to pg_class, but there's much less HOT pruning on them because there's no loop of VACUUMs. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: