Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution

On Wed, 16 Jul 2025 at 01:10, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> And the relevant portion of the backtrace:
> #7 ExecGetUpdateNewTuple (oldSlot=0x55b0842d0288,
> #planSlot=0x55b084249d68, relinfo=0x55b0836a9b88) at
> #executor/./build/../src/backend/executor/nodeModifyTable.c:752
> #8 ExecBRUpdateTriggers (estate=0x55b08369a708,
> #epqstate=0x55b0836a9a68, relinfo=0x55b0836a9b88,
> #tupleid=0x7fffc373628a, fdw_trigtuple=0x0, newslot=0x55b083720eb0,
> #tmresult=0x7fffc37361d0, tmfd=0x7fffc37362e0) at
> #commands/./build/../src/backend/commands/trigger.c:2979
> #9 0x000055b08158628e in ExecUpdatePrologue
> #(context=context(at)entry=0x7fffc37362c0,
> #resultRelInfo=resultRelInfo(at)entry=0x55b0836a9b88,
> #tupleid=tupleid(at)entry=0x7fffc373628a, oldtuple=oldtuple(at)entry=0x0,
> #slot=slot(at)entry=0x55b083720eb0, result=result(at)entry=0x7fffc37361d0)
> #at executor/./build/../src/backend/executor/nodeModifyTable.c:1949
> #10 0x000055b081587e75 in ExecMergeMatched (context=<optimized out>,
> #resultRelInfo=<optimized out>, tupleid=0x7fffc373628a, oldtuple=0x0,
> #canSetTag=false, matched=0x7fffc3736290) at
> #executor/./build/../src/backend/executor/nodeModifyTable.c:3023

Hmm, I can see the problem. This particular stack trace should never happen:

#7 ExecGetUpdateNewTuple
#8 ExecBRUpdateTriggers
#9 ExecUpdatePrologue
#10 ExecMergeMatched

ExecBRUpdateTriggers() only calls ExecGetUpdateNewTuple() if
GetTupleForTrigger() sets epqslot_candidate to a non-null value, and
GetTupleForTrigger() should only set epqslot_candidate (*epqslot) to
non-null if we're not doing a MERGE (see commit 9321c79).

The problem, however, is that GetTupleForTrigger() tests for MERGE by doing

if (estate->es_plannedstmt->commandType != CMD_MERGE)

which doesn't work if the MERGE is inside a CTE. So we need a
different way for ExecBRUpdateTriggers() / GetTupleForTrigger() to
know that it's being called from within a MERGE.

Regards,
Dean