Re: BUG #17809: MERGE ... UPDATE fails with BEFORE ROW UPDATE trigger when target row updated concurrently
Dean Rasheed <dean.a.rasheed@gmail.com>
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-03-12T11:14:29Z
Lists: pgsql-bugs
Attachments
- bug-17809-v4.patch (text/x-patch) patch v4
- bug-17809-v4-15.patch (text/x-patch) patch v4
On Sat, 11 Mar 2023 at 18:12, Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > > Attached is an updated patch that I'm more happy with now, and a > slightly modified one for v15, keeping the trigger API > backwards-compatible for extensions. > Going over this again, I spotted another couple of things: Passing recheckIndexes to ExecUpdateEpilogue() is pointless, since that's something that's only ever computed and used locally within ExecUpdateEpilogue(). It's also pointless for the caller to list_free() it, since the caller only has a pointer to the empty list, not the list built in ExecUpdateEpilogue(), which it should free. This is pretty harmless, but I might as well tidy it up while hacking on this. If a BEFORE ROW trigger returns NULL to skip an update or delete, ExecMergeMatched() will still update estate->es_processed, and so the final row count in the command tag will be wrong. I'll tackle that in a follow-on patch, since it's really a separate bug. Regards, Dean
Commits
-
Fix MERGE command tag for actions blocked by BEFORE ROW triggers.
- 7b14e20b12cc 16.0 landed
- da6257eee35d 15.3 landed