Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Mahendra Singh Thalor <mahi6run@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-01-24T17:05:40Z
Lists: 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.
Commits
-
Reinstate HEAP_XMAX_LOCK_ONLY|HEAP_KEYS_UPDATED as allowed
- bf518fefacc7 10.17 landed
- 8deb6b38dc4c 14.0 landed
- 28f4b61083b2 13.3 landed
- 2796ae2ad253 12.7 landed
- 2583917075ae 11.12 landed
- 0ccebe779dc0 9.6.22 landed