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
