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

On Tue, Jul 15, 2025 at 02:13:53PM -0400, Tom Lane wrote:
> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > During testing a flow in an app, I encountered a segfault that only happens
> > during parallel execution:
> > https://gist.github.com/joy4eg/708458e204f52129a8e54a13534586b7
>
> This report isn't terribly helpful, since you have not explained
> how to trigger the crash. If we can't duplicate it, it's hard
> to decide what is the appropriate fix.

For the sake of visibility if the information on github gets lost, the
change can be summarized by this query pattern, but we don't have any
information about the end of the query:

WITH replaced AS (
DELETE FROM replaceable_events_before_update
WHERE replaced_by_id = ANY($1)
RETURNING attr_list_1, [...] ),
source_data (attr_list_2) AS (
SELECT * from replaced UNION ALL
VALUES (attr_list_3 ...

That's most likely generated a MERGE by an ORM to have these many
parameters and columns listed. Without the full pattern or an idea of
the schema as this includes triggers, what we can do is limited, as
Tom says.

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

If you could extract the query string from the backtrace, that would
be one piece of information. With triggers and MERGE in mind, it may
be possible to reproduce something.
--
Michael