From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, y(at)lll(dot)gd, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution |
Date: | 2025-07-16 10:42:33 |
Message-ID: | CAEZATCUahLe8Lvi7XHV6Eo=Tg46iJ2Rmfw0k6AH5GQbfOjENHQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, 16 Jul 2025 at 10:55, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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
Attachment | Content-Type | Size |
---|---|---|
merge-bug.patch | text/x-patch | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-07-16 10:48:55 | Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution |
Previous Message | Dean Rasheed | 2025-07-16 09:55:44 | Re: BUG #18986: SIGSEGV in nodeModifyTable.c during Parallel Execution |