Tomas Vondra <tomas.von...@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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers