Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal
Date
Msg-id 2463977.1596578434@sss.pgh.pa.us
Whole thread Raw
In response to Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal
List pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> On Tue, Aug 4, 2020 at 1:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> while the INSERT_IN_PROGRESS case has none.  Simple symmetry
>> would suggest that the INSERT_IN_PROGRESS case should be
>> 
>>     if (checking_uniqueness ||
>>         HeapTupleIsHeapOnly(heapTuple))
>>         // wait

> I had exactly the same intuition.

>> but I'm not 100% convinced that that's right.

> Why doubt that explanation?

First, it's not clear that this is an exact inverse, because
HeapTupleIsHotUpdated does more than check the HOT_UPDATED flag.
Second, I think there remains some doubt as to whether the
DELETE_IN_PROGRESS case is right either.  If we were forcing
a wait for *every* in-doubt HOT-chain element, not only non-last
ones (or non-first ones for the INSERT case, if we use the above
fix) then it'd be quite clear that we're safe.  But if we want
to keep the optimization then I think maybe closer analysis is
warranted.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Confusing behavior of create table like
Next
From: Jehan-Guillaume de Rorthais
Date:
Subject: Re: [patch] demote