Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal

I have nothing new to add, but wanted to point out this is still an issue.

This is on the v13 Opened Items list - for lack of anywhere else to put them, I
also added two other, unresolved issues.

https://wiki.postgresql.org/index.php?title=PostgreSQL_13_Open_Items&type=revision&diff=35624&oldid=35352

On Tue, Aug 04, 2020 at 06:00:34PM -0400, Tom Lane wrote:
> Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> > On Tue, Aug 4, 2020 at 1:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> while the INSERT_IN_PROGRESS case has none. Simple symmetry
> >> would suggest that the INSERT_IN_PROGRESS case should be
> >>
> >> if (checking_uniqueness ||
> >> HeapTupleIsHeapOnly(heapTuple))
> >> // wait
>
> > I had exactly the same intuition.
>
> >> but I'm not 100% convinced that that's right.
>
> > Why doubt that explanation?
>
> First, it's not clear that this is an exact inverse, because
> HeapTupleIsHotUpdated does more than check the HOT_UPDATED flag.
> Second, I think there remains some doubt as to whether the
> DELETE_IN_PROGRESS case is right either. If we were forcing
> a wait for *every* in-doubt HOT-chain element, not only non-last
> ones (or non-first ones for the INSERT case, if we use the above
> fix) then it'd be quite clear that we're safe. But if we want
> to keep the optimization then I think maybe closer analysis is
> warranted.