Re: BUG #17197: Assert failed on inserting index tuples after VACUUM

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: BUG #17197: Assert failed on inserting index tuples after VACUUM
Дата
Msg-id CAH2-WzkKtu=o=H_xFD1NS1pp-KDUq_akMVnLuYOAN+z4=sZTxA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17197: Assert failed on inserting index tuples after VACUUM  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: BUG #17197: Assert failed on inserting index tuples after VACUUM  (Alexander Lakhin <exclusion@gmail.com>)
Список pgsql-bugs
On Mon, Sep 20, 2021 at 1:35 PM Peter Geoghegan <pg@bowt.ie> wrote:
> If this is a TID that came from the index then I cannot see what
> business VACUUM has with setting it LP_UNUSED (and then truncating it
> away entirely) -- clearly VACUUM should have deleted it from the index
> first. Is there any easy way for you to check where this offnum came
> from?

Oh, wait. The problem now seems obvious: the assertion is wrong, and
should just be removed. The assertion was arguably a bit too zealous
when 4228817449 went in, and clearly became totally wrong a few months
later, following commit 3c3b8a4b.

Before commit 3c3b8a4b our failing offset number would have at least
found an LP_UNUSED item -- so no assertion failure. After that commit
the offset's line pointer might actually be positioned "past the end
of the line pointer array". But that is a valid state for a heap
page/HOT chain to have -- so the assertion has it wrong.

It is actually the job of code that traverses HOT chains to deal with
these sorts of inconsistencies, at least following commit 3c3b8a4b --
the responsibility does not belong to the pruning process itself.
That's why commit 3c3b8a4b went to the trouble of tightening things up
elsewhere (e.g., in heap_get_root_tuples()).

I'll push a fix soon. Thanks for the report!

-- 
Peter Geoghegan



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: BUG #17197: Assert failed on inserting index tuples after VACUUM
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #17198: Planning time too high when execute query on standby cluster