From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: y@lll.gd
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution
Date: Wed, 16 Jul 2025 09:10:36 +0900
Message-ID: <aHbt_HkrM3TTH61j@paquier.xyz> (raw)
In-Reply-To: <937261.1752603233@sss.pgh.pa.us>
References: <18986-e7a8aac3d339fa47@postgresql.org>
<937261.1752603233@sss.pgh.pa.us>
On Tue, Jul 15, 2025 at 02:13:53PM -0400, Tom Lane wrote:
> PG Bug reporting form <noreply@postgresql.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@entry=0x7fffc37362c0,
#resultRelInfo=resultRelInfo@entry=0x55b0836a9b88,
#tupleid=tupleid@entry=0x7fffc373628a, oldtuple=oldtuple@entry=0x0,
#slot=slot@entry=0x55b083720eb0, result=result@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
Attachments:
[application/pgp-signature] signature.asc (832B, ../aHbt_HkrM3TTH61j@paquier.xyz/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: michael@paquier.xyz, tgl@sss.pgh.pa.us, y@lll.gd, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution
In-Reply-To: <aHbt_HkrM3TTH61j@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox