On Tue, Jul 28, 2020 at 10:37 AM Peter Geoghegan <p...@bowt.ie> wrote: > It's starting to look more like that. I can reproduce the bug by > running the REINDEX in a tight loop while "make installcheck" runs. It > looks as if the two tuples passed to comparetup_index_btree() are > separate tuples that each point to the same heap TID.
Evidently this is an old bug. The assertion that fails was added to Postgres 12, but that isn't significant. The invariant we see violated here has nothing to do with any of my B-Tree work -- it would have been reasonable to add the same assertion to Postgres 9.5. If I add the same assertion to 9.5 now, I find that the same steps reproduce the problem -- "REINDEX INDEX pg_class_tblspc_relfilenode_index" run in a tight loop connected to the regression database, concurrent with a "make installcheck". I still don't know what's going on here, but I find it suspicious that some relevant tuples go through the HEAPTUPLE_INSERT_IN_PROGRESS + !TransactionIdIsCurrentTransactionId() path of heapam_index_build_range_scan(). After all, if this wasn't a system catalog index then we'd expect to see "concurrent insert in progress within table \"%s\"" WARNING output. -- Peter Geoghegan
