| 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-08-04 22:00:34 |
| Message-ID: | 2463977.1596578434@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:
> 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jehan-Guillaume de Rorthais | 2020-08-04 22:04:53 | Re: [patch] demote |
| Previous Message | Peter Eisentraut | 2020-08-04 21:50:38 | Re: Confusing behavior of create table like |