On Tue, Jul 28, 2020 at 2:46 PM Peter Geoghegan <p...@bowt.ie> wrote: > 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.
I mentioned that the unique index aspect was added by commit 1ddc2703 in 2010 (the new-style VACUUM FULL deadlock commit that added the "if (checking_uniqueness)" condition). Turns out that that had bugs that were fixed in 2011's commit 520bcd9c9bb (at least I think so based on a reading of the latter commit's commit message) -- though those were in the DELETE_IN_PROGRESS case. Perhaps 2011's commit 520bcd9c9bb missed similar HEAPTUPLE_INSERT_IN_PROGRESS issues that manifest themselves within Justin's test case now? -- Peter Geoghegan
