Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution
Dean Rasheed <dean.a.rasheed@gmail.com>
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, y@lll.gd, pgsql-bugs@lists.postgresql.org
Date: 2025-07-16T10:42:33Z
Lists: pgsql-bugs
Attachments
- merge-bug.patch (text/x-patch) patch
On Wed, 16 Jul 2025 at 10:55, Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > > 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. Attached is a reproducer using the merge-match-recheck isolation test. I believe that the bug only goes back to v17, because MERGE could not appear inside a CTE prior to that. I think that best thing to do is pass the commandType to ExecBRUpdateTriggers(), except that in v17 we shouldn't change the signature of ExecBRUpdateTriggers(), so a wrapper function will be needed, similar to what 9321c79 did. Question: Is it OK to change the signature of ExecBRUpdateTriggers() in v18? Regards, Dean
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix concurrent update trigger issues with MERGE in a CTE.
- 91ad1bdef8e4 17.6 landed
- 27c7c11366f7 18.0 landed
- 5022ff250eeb 19 (unreleased) landed
-
Stamp 17.5.
- 5e2f3df49d42 17.5 cited
-
Fix concurrent update issues with MERGE.
- 9321c79c86e6 16.0 cited