On Tue, Jul 28, 2020 at 10:37 AM Peter Geoghegan <pg@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