Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination
Date
Msg-id CAOBaU_Yrz3HrgT_kpiet9TLHLCGPzRQ0CPcfvP-nDv=1KY3bxg@mail.gmail.com
Whole thread Raw
In response to Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination  (Mahendra Singh Thalor <mahi6run@gmail.com>)
List pgsql-hackers
On Mon, Jan 25, 2021 at 12:06 AM Mahendra Singh Thalor
<mahi6run@gmail.com> wrote:
>
> On Sun, 24 Jan 2021 at 11:48, Julien Rouhaud <rjuju123@gmail.com> wrote:
> >
> > Hi,
> >
> > I'm not really familiar with this part of the code, so it's not exactly clear
> > to me if some logic is missing in compute_new_xmax_infomask() /
> > heap_prepare_insert(), or if this should actually be an allowed combination of
> > hint bit.
>
> Thanks Juliean for reporting this. I am also able to reproduce this assert.

Thanks for looking at it!
>
> Small test case to reproduce:
>>
>> DROP TABLE IF EXISTS t1;
>> CREATE TABLE t1(id integer, val text);
>> INSERT INTO t1 SELECT i, 'val' FROM generate_series(1, 2) i;
>>
>> BEGIN;
>> SAVEPOINT s1;
>> SELECT 1 FROM t1 WHERE id = 2 FOR UPDATE;
>> UPDATE t1 SET val = 'hoho' WHERE id = 2;
>> release s1;
>> SELECT 1 FROM t1 WHERE id = 2 FOR UPDATE;
>> UPDATE t1 SET val = 'hoho' WHERE id = 2;
>
>
> If we remove the "release s1;" step from the test case, then we are not getting this assert failure.

Yes, this is the smallest reproducer that could trigger the problem,
and the release is required.



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination
Next
From: Mark Rofail
Date:
Subject: Re: [HACKERS] GSoC 2017: Foreign Key Arrays