On Tue, Jul 28, 2020 at 2:46 PM Peter Geoghegan <pg@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