On Tue, Jul 28, 2020 at 1:26 PM Peter Geoghegan <p...@bowt.ie> wrote: > On Tue, Jul 28, 2020 at 1:04 PM Tom Lane <t...@sss.pgh.pa.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