Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination

On Sun, 24 Jan 2021 at 11:48, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>
> Hi,
>
> While working on pg14 compatibility for an extension relying on an
apparently
> uncommon combination of FOR UPDATE and stored function calls, I hit some
new
> Asserts introduced in 866e24d47db (Extend amcheck to check heap pages):
>
> + /*
> + * Do not allow tuples with invalid combinations of hint bits to
be placed
> + * on a page. These combinations are detected as corruption by
the
> + * contrib/amcheck logic, so if you disable one or both of these
> + * assertions, make corresponding changes there.
> + */
> + Assert(!((tuple->t_data->t_infomask & HEAP_XMAX_LOCK_ONLY) &&
> + (tuple->t_data->t_infomask2 &
HEAP_KEYS_UPDATED)));
>
>
> I attach a simple self contained script to reproduce the problem, the last
> UPDATE triggering the Assert.
>
> 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.

*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.

*Stack trace:*

> warning: Unexpected size of section `.reg-xstate/123318' in core file.
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `postgres: mahendrathalor postgres [local] UPDATE
> '.
> Program terminated with signal SIGABRT, Aborted.
>
> warning: Unexpected size of section `.reg-xstate/123318' in core file.
> #0 __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0 __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1 0x00007fb50a7c88b1 in __GI_abort () at abort.c:79
> #2 0x00005612a63f7c84 in ExceptionalCondition (
> conditionName=0x5612a64da470 "!((tuple->t_data->t_infomask &
> HEAP_XMAX_LOCK_ONLY) && (tuple->t_data->t_infomask2 & HEAP_KEYS_UPDATED))",
> errorType=0x5612a64da426 "FailedAssertion", fileName=0x5612a64da420
> "hio.c", lineNumber=57) at assert.c:69
> #3 0x00005612a597e76b in RelationPutHeapTuple (relation=0x7fb50ce37fc0,
> buffer=163, tuple=0x5612a795de18, token=false) at hio.c:56
> #4 0x00005612a5955d32 in heap_update (relation=0x7fb50ce37fc0,
> otid=0x7ffc8b5e30d2, newtup=0x5612a795de18, cid=0, crosscheck=0x0,
> wait=true, tmfd=0x7ffc8b5e3060,
> lockmode=0x7ffc8b5e3028) at heapam.c:3791
> #5 0x00005612a596ebdc in heapam_tuple_update (relation=0x7fb50ce37fc0,
> otid=0x7ffc8b5e30d2, slot=0x5612a794d348, cid=3, snapshot=0x5612a793d620,
> crosscheck=0x0, wait=true,
> tmfd=0x7ffc8b5e3060, lockmode=0x7ffc8b5e3028,
> update_indexes=0x7ffc8b5e3025) at heapam_handler.c:327
> #6 0x00005612a5da745d in table_tuple_update (rel=0x7fb50ce37fc0,
> otid=0x7ffc8b5e30d2, slot=0x5612a794d348, cid=3, snapshot=0x5612a793d620,
> crosscheck=0x0, wait=true,
> tmfd=0x7ffc8b5e3060, lockmode=0x7ffc8b5e3028,
> update_indexes=0x7ffc8b5e3025) at ../../../src/include/access/tableam.h:1422
> #7 0x00005612a5dab6ef in ExecUpdate (mtstate=0x5612a794bc20,
> resultRelInfo=0x5612a794be58, tupleid=0x7ffc8b5e30d2, oldtuple=0x0,
> slot=0x5612a794d348, planSlot=0x5612a794d1f8,
> epqstate=0x5612a794bd18, estate=0x5612a794b9b0, canSetTag=true) at
> nodeModifyTable.c:1498
> #8 0x00005612a5dadb17 in ExecModifyTable (pstate=0x5612a794bc20) at
> nodeModifyTable.c:2254
> #9 0x00005612a5d4fdc5 in ExecProcNodeFirst (node=0x5612a794bc20) at
> execProcnode.c:450
> #10 0x00005612a5d3bd3a in ExecProcNode (node=0x5612a794bc20) at
> ../../../src/include/executor/executor.h:247
> #11 0x00005612a5d40764 in ExecutePlan (estate=0x5612a794b9b0,
> planstate=0x5612a794bc20, use_parallel_mode=false, operation=CMD_UPDATE,
> sendTuples=false, numberTuples=0,
> direction=ForwardScanDirection, dest=0x5612a7946d38,
> execute_once=true) at execMain.c:1542
> #12 0x00005612a5d3c8e2 in standard_ExecutorRun (queryDesc=0x5612a79468c0,
> direction=ForwardScanDirection, count=0, execute_once=true) at
> execMain.c:364
> #13 0x00005612a5d3c5aa in ExecutorRun (queryDesc=0x5612a79468c0,
> direction=ForwardScanDirection, count=0, execute_once=true) at
> execMain.c:308
> #14 0x00005612a612d78a in ProcessQuery (plan=0x5612a7946c48,
> sourceText=0x5612a787b570 "UPDATE t1 SET val = 'hoho' WHERE id = 2;",
> params=0x0, queryEnv=0x0,
> dest=0x5612a7946d38, qc=0x7ffc8b5e3570) at pquery.c:160
> #15 0x00005612a61306f6 in PortalRunMulti (portal=0x5612a78dd5f0,
> isTopLevel=true, setHoldSnapshot=false, dest=0x5612a7946d38,
> altdest=0x5612a7946d38, qc=0x7ffc8b5e3570)
> at pquery.c:1267
> #16 0x00005612a612f256 in PortalRun (portal=0x5612a78dd5f0,
> count=9223372036854775807, isTopLevel=true, run_once=true,
> dest=0x5612a7946d38, altdest=0x5612a7946d38,
> qc=0x7ffc8b5e3570) at pquery.c:779
> #17 0x00005612a612266f in exec_simple_query (query_string=0x5612a787b570
> "UPDATE t1 SET val = 'hoho' WHERE id = 2;") at postgres.c:1240
> #18 0x00005612a612b8dd in PostgresMain (argc=1, argv=0x7ffc8b5e3790,
> dbname=0x5612a78a74f0 "postgres", username=0x5612a78a74c8 "mahendrathalor")
> at postgres.c:4394
> #19 0x00005612a5fd5bf0 in BackendRun (port=0x5612a789ec00) at
> postmaster.c:4484
> #20 0x00005612a5fd4f46 in BackendStartup (port=0x5612a789ec00) at
> postmaster.c:4206
> #21 0x00005612a5fcd301 in ServerLoop () at postmaster.c:1730
> #22 0x00005612a5fcc4fe in PostmasterMain (argc=5, argv=0x5612a7873e70) at
> postmaster.c:1402
> #23 0x00005612a5e16d9a in main (argc=5, argv=0x5612a7873e70) at main.c:209
>

I am also trying to understand infomask and all.

Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com