| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, James Coleman <jtc331(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
| Subject: | Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal |
| Date: | 2020-07-28 20:04:26 |
| Message-ID: | 1237442.1595966666@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2020-07-28 20:26:10 | Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal |
| Previous Message | Peter Geoghegan | 2020-07-28 19:53:09 | Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal |