Peter Geoghegan <p...@bowt.ie> writes: > I also find it suspicious that I can no longer produce the assertion > failure once I force all non-unique system catalog indexes (such as > Justin's repro index, pg_class_tblspc_relfilenode_index) to go through > the HEAPTUPLE_INSERT_IN_PROGRESS + > !TransactionIdIsCurrentTransactionId() handling for unique indexes > shown here:
Hmm... > Actually...was the code *originally* designed to avoid this issue? 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. Or, perhaps, REINDEX is somehow scanning the same TID twice, and generating indeed-duplicate index entries? regards, tom lane