Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On 10/30/2017 09:03 PM, Tom Lane wrote:
>> [ scratches head ... ] Not sure how that could've introduced any
>> problems? Will look.
> Not sure, but I can confirm Michael's findings - I've been unable to
> reproduce the issue on 1a4be103a5 even after 20 minutes, and on
> 24992c6db9 it failed after only 2.
Hmm. The index offnum being complained of is one past the end of the
lp array. I think I see what about that commit changed the behavior:
the old code for PageIndexDeleteNoCompact never changed the length
of the lp array, except in the corner case where the page is becoming
completely empty. The new code will shorten the lp array (decrease
phdr->pd_lower) if it's told to remove the last item. So if you make
two successive calls specifying the same offnum, and it's the last one
on the page, the second one will fail with the symptoms we see here.
However, so far as I can see, a sequence like that would have failed
before too, just with a different error message, because once the
first call had marked the item unused, the second call would not see
it as a candidate to match. So I'm not quite sure how that's related
... but it seems like it must be.
Anyway, my opinion ATM is that PageIndexTupleDeleteNoCompact is fine,
and what we're looking at is some kind of bug in summarize_range
or brin_doupdate, causing them to pass a offset beyond the end of
the page in some corner case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers