Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal

On Tue, Jul 28, 2020 at 1:26 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Tue, Jul 28, 2020 at 1:04 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > No, I don't think so. It was designed for the case of unique key X
> > being inserted immediately after a deletion of the same key. The
> > deleted tuple is presumably not yet vacuumed-away, so the new tuple
> > should have a different TID. In no case should we have multiple index
> > tuples pointing at the same TID; that would imply that somebody failed
> > to vacuuum away an old index entry before freeing up the heap TID.
>
> It looks like one HOT chain.

The fact remains that this function (originally known as
IndexBuildHeapScan(), now heapam_index_build_range_scan()) did not
care about whether or not the index is unique for about 3 years
(excluding the tupleIsAlive stuff, which was always there, even before
HOT). The original HOT commit (commit 282d2a03dd3) said nothing about
unique indexes in the relevant path (the HEAPTUPLE_INSERT_IN_PROGRESS
+ !TransactionIdIsCurrentTransactionId() "concurrent system catalog
insert" path). The need to wait here really did seem to be all about
not getting duplicate TIDs (i.e. respecting the basic HOT invariant)
back in 2007.

--
Peter Geoghegan