=?UTF-8?Q?Piotr_W=C5=82odarczyk?= <piotrwlodarczyk89@gmail.com> writes:
> sorry for the late reply, but it was not so easy to get more logs. So what
> we have now is listed below:
> (gdb) bt
> #0 0x0000000000616912 in EvalPlanQualBegin (epqstate=epqstate@entry=0x2ae9520)
> at execMain.c:2735
> #1 0x0000000000616cfb in EvalPlanQual (epqstate=epqstate@entry=0x2ae9520,
> relation=relation@entry=0x7f694c76f838, rti=14,
> inputslot=inputslot@entry=0x31bc408)
> at execMain.c:2454
> #2 0x0000000000638bdf in ExecUpdate (mtstate=mtstate@entry=0x2ae9428,
> tupleid=0x7ffc94e3cf40, oldtuple=0x0, slot=<optimized out>,
> planSlot=0x312fc28, epqstate=epqstate@entry=0x2ae9520,
> estate=estate@entry=0x2aff450,
> canSetTag=true) at nodeModifyTable.c:1387
> #3 0x000000000063914d in ExecModifyTable (pstate=0x2ae9428) at
> nodeModifyTable.c:2223
OK, so that confirms my suspicion that it was an EvalPlanQual issue
(hence, you need concurrent updates on the same row to trigger it).
I believe this might be the same bug we isolated and fixed just a
couple of days ago:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=87fed2a197abc1397b63ee74b3fa7eb20471fff5
The stack trace looks the same as what Oleksii showed in that thread
for a non-assert build. As far as I know, that bug only triggers if
a single ModifyTable plan node has to run EPQ checks for more than
one target table --- so, is this query updating a partitioned table
or inheritance tree, and is it plausible that it had to update rows
in more than one sub-table, and that some other transaction(s) were
concurrently updating those same rows?
regards, tom lane
