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

On Mon, Sep 20, 2021 at 1:01 PM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> Reproduced on REL_14_STABLE and master.
> The first bad commit is 3c3b8a4b.

I committed both the patch that added the failing assertion (bugfix
commit 4228817449) and the commit that allowed VACUUM to truncate line
pointers (commit 3c3b8a4b, "the first bad commit"). So I am very much
involved with both sides of the assertion failure that you found.

I am tempted to say that I should simply remove the assertion that
fails. But I won't do that before understanding what's going on here.

This is the assertion in question:

offnum = ItemPointerGetOffsetNumber(htid);
priorXmax = InvalidTransactionId; /* cannot check first XMIN */
for (;;)
{
ItemId lp;
HeapTupleHeader htup;

/* Some sanity checks */
if (offnum < FirstOffsetNumber || offnum > maxoff)
{
Assert(false);
break;
}

Similar code from heap_prune_chain() does not have the assertion. In
fact it's almost identical. This "can't happen" assertion was my own
recent addition, that could have easily been left out of commit
4228817449.

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?

--
Peter Geoghegan