Re: PostgreSQL12 crash bug report

yi huang <yi(dot)codeplayer(at)gmail(dot)com> writes:
> [ crashes with ]
> $ pgbench -h 127.0.0.1 -p 5432 -U exchange exchange -T 2 -c 4 -f /tmp/test.sql

Thanks for the report!

Note that this doesn't fail if you just run test.sql by itself, but
it does soon fall over as described when running multiple copies in
parallel. Unsurprisingly given that, the crash is inside EvalPlanQual:

(gdb) bt
#0 memcpy () at ../sysdeps/x86_64/memcpy.S:526
#1 0x00000000004863b1 in fill_val (tupleDesc=0x18c7060,
values=<value optimized out>, isnull=0x195e198,
data=<value optimized out>, data_size=148670068,
infomask=<value optimized out>, bit=0x7f07aef4207f "\017")
at heaptuple.c:247
#2 heap_fill_tuple (tupleDesc=0x18c7060, values=<value optimized out>,
isnull=0x195e198, data=<value optimized out>, data_size=148670068,
infomask=<value optimized out>, bit=0x7f07aef4207f "\017")
at heaptuple.c:336
#3 0x0000000000486921 in heap_form_tuple (tupleDescriptor=0x18c7060,
values=0x7ffc691d58b0, isnull=0x195e198) at heaptuple.c:1090
#4 0x00000000004ddf78 in toast_build_flattened_tuple (tupleDesc=0x18c7060,
values=<value optimized out>, isnull=0x195e198) at tuptoaster.c:1336
#5 0x00000000006441f0 in ExecEvalWholeRowVar (state=<value optimized out>,
op=0x1958030, econtext=<value optimized out>) at execExprInterp.c:4019
#6 0x0000000000647602 in ExecInterpExpr (state=0x1957ea0, econtext=0x19576a0,
isnull=0x7ffc691d8dff) at execExprInterp.c:519
#7 0x00000000006543ef in ExecEvalExprSwitchContext (
node=<value optimized out>, accessMtd=0x67a140 <ValuesNext>,
recheckMtd=0x679f00 <ValuesRecheck>)
at ../../../src/include/executor/executor.h:307
#8 ExecProject (node=<value optimized out>, accessMtd=0x67a140 <ValuesNext>,
recheckMtd=0x679f00 <ValuesRecheck>)
at ../../../src/include/executor/executor.h:341
#9 ExecScan (node=<value optimized out>, accessMtd=0x67a140 <ValuesNext>,
recheckMtd=0x679f00 <ValuesRecheck>) at execScan.c:199
#10 0x00000000006698dc in ExecProcNode (node=0x19573d8)
at ../../../src/include/executor/executor.h:239
#11 MultiExecPrivateHash (node=0x19573d8) at nodeHash.c:164
#12 MultiExecHash (node=0x19573d8) at nodeHash.c:114
#13 0x000000000066b685 in ExecHashJoinImpl (pstate=0x1939d08)
at nodeHashjoin.c:291
#14 ExecHashJoin (pstate=0x1939d08) at nodeHashjoin.c:572
#15 0x000000000064af7f in ExecProcNode (epqstate=<value optimized out>)
at ../../../src/include/executor/executor.h:239
#16 EvalPlanQualNext (epqstate=<value optimized out>) at execMain.c:2692
#17 0x000000000064b502 in EvalPlanQual (estate=<value optimized out>,
epqstate=0x18b5420, relation=<value optimized out>, rti=4,
inputslot=0x195dfc0) at execMain.c:2475
#18 0x0000000000675f09 in ExecUpdate (mtstate=0x18b5328,
tupleid=0x7ffc691d9130, oldtuple=0x0, slot=<value optimized out>,
planSlot=0x18ca138, epqstate=0x18b5420, estate=0x18b4558, canSetTag=true)
at nodeModifyTable.c:1389
#19 0x000000000067668d in ExecModifyTable (pstate=0x18b5328)
at nodeModifyTable.c:2226
#20 0x000000000064d547 in ExecProcNode (queryDesc=0x18b4148,
direction=<value optimized out>, count=0, execute_once=40)
at ../../../src/include/executor/executor.h:239
#21 ExecutePlan (queryDesc=0x18b4148, direction=<value optimized out>,
count=0, execute_once=40) at execMain.c:1648
#22 standard_ExecutorRun (queryDesc=0x18b4148,
direction=<value optimized out>, count=0, execute_once=40)
at execMain.c:365
#23 0x00000000007c32ab in ProcessQuery (plan=<value optimized out>,
sourceText=0x17b7f28 "with tmp(id, avail_amount, deal_value, update_id) as (values (76107497731002368,0.00,16546.90746,76107519298113537),(76107514491441155,0.606,5808.03795,76107519298113537))\nupdate t_order set avail_amo"...,
params=0x0, queryEnv=0x0, dest=<value optimized out>,
completionTag=0x7ffc691d9430 "") at pquery.c:161
#24 0x00000000007c3613 in PortalRunMulti (portal=0x181dc48, isTopLevel=true,
setHoldSnapshot=false, dest=0x7f07b7f9fce0, altdest=0x7f07b7f9fce0,
completionTag=0x7ffc691d9430 "") at pquery.c:1283
#25 0x00000000007c3d80 in PortalRun (portal=0x181dc48,
count=9223372036854775807, isTopLevel=true, run_once=true,
dest=0x7f07b7f9fce0, altdest=0x7f07b7f9fce0,
completionTag=0x7ffc691d9430 "") at pquery.c:796
#26 0x00000000007c0001 in exec_simple_query (
...

As per the stack trace, we're trying to build a new tuple for the output
of a ValuesScan node, but the targetlist for that seems completely insane:
heap_form_tuple is being given a 15-column tupdesc that includes

(gdb) p tupleDescriptor->attrs[1]
$8 = {attrelid = 0, attname = {data = "side", '\000' <repeats 59 times>},
atttypid = 35644, attstattarget = -1, attlen = 4, attnum = 2, attndims = 0,
attcacheoff = 8, atttypmod = -1, attbyval = true, attstorage = 112 'p',
attalign = 105 'i', attnotnull = false, atthasdef = false,
atthasmissing = false, attidentity = 0 '\000', attgenerated = 0 '\000',
attisdropped = false, attislocal = true, attinhcount = 0, attcollation = 0}

which seems to be the column that we have a bogus Datum for. But what's
the code doing expecting that to be available from the ValueScan? It's a
column of t_order. And the other data is all wrong too: that composite
type should surely not have attlen = 4 nor attbyval = true.

"explain verbose" claims that the Values node should be returning

-> Values Scan on "*VALUES*" (cost=0.00..0.03 rows=2 width=184)
Output: "*VALUES*".column2, "*VALUES*".column3, "*VALUES*".column4, "*VALUES*".*, "*VALUES*".column1

so it seems like somehow we've got wrong info in the EPQ context.
I wonder if this is related to the "Hash join explain is broken"
thread.

regards, tom lane