database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-22 14:32:25 +03:00
Code Activity

Fix concurrent update trigger issues with MERGE in a CTE.

Browse Source 
If a MERGE inside a CTE attempts an UPDATE or DELETE on a table with
BEFORE ROW triggers, and a concurrent UPDATE or DELETE happens, the
merge code would fail (crashing in the case of an UPDATE action, and
potentially executing the wrong action for a DELETE action).

This is the same issue that 9321c79c86 attempted to fix, except now
for a MERGE inside a CTE. As noted in 9321c79c86, what needs to happen
is for the trigger code to exit early, returning the TM_Result and
TM_FailureData information to the merge code, if a concurrent
modification is detected, rather than attempting to do an EPQ
recheck. The merge code will then do its own rechecking, and rescan
the action list, potentially executing a different action in light of
the concurrent update. In particular, the trigger code must never call
ExecGetUpdateNewTuple() for MERGE, since that is bound to fail because
MERGE has its own per-action projection information.

Commit 9321c79c86 did this using estate->es_plannedstmt->commandType
in the trigger code to detect that a MERGE was being executed, which
is fine for a plain MERGE command, but does not work for a MERGE
inside a CTE. Fix by passing that information to the trigger code as
an additional parameter passed to ExecBRUpdateTriggers() and
ExecBRDeleteTriggers().

Back-patch as far as v17 only, since MERGE cannot appear inside a CTE
prior to that. Additionally, take care to preserve the trigger ABI in
v17 (though not in v18, which is still in beta).

Bug: #18986
Reported-by: Yaroslav Syrytsia <me@ys.lc>
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/18986-e7a8aac3d339fa47@postgresql.org
Backpatch-through: 17
This commit is contained in:
Dean Rasheed
2025-07-18 09:55:43 +01:00
parent 62c3b4cd9d
commit 5022ff250e
6 changed files with 89 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
src/backend/commands/trigger.c
View File

@@ -80,6 +80,7 @@ static bool GetTupleForTrigger(EState *estate,
ItemPointer tid,
LockTupleMode lockmode,
TupleTableSlot *oldslot,
bool do_epq_recheck,
TupleTableSlot **epqslot,
TM_Result *tmresultp,
TM_FailureData *tmfdp);
@@ -2693,7 +2694,8 @@ ExecBRDeleteTriggers(EState *estate, EPQState *epqstate,
HeapTuple fdw_trigtuple,
TupleTableSlot **epqslot,
TM_Result *tmresult,
TM_FailureData *tmfd)
TM_FailureData *tmfd,
bool is_merge_delete)
{
TupleTableSlot *slot = ExecGetTriggerOldSlot(estate, relinfo);
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
@@ -2708,9 +2710,17 @@ ExecBRDeleteTriggers(EState *estate, EPQState *epqstate,
{
TupleTableSlot *epqslot_candidate = NULL;
/*
* Get a copy of the on-disk tuple we are planning to delete. In
* general, if the tuple has been concurrently updated, we should
* recheck it using EPQ. However, if this is a MERGE DELETE action,
* we skip this EPQ recheck and leave it to the caller (it must do
* additional rechecking, and might end up executing a different
* action entirely).
*/
if (!GetTupleForTrigger(estate, epqstate, relinfo, tupleid,
LockTupleExclusive, slot, &epqslot_candidate,
tmresult, tmfd))
LockTupleExclusive, slot, !is_merge_delete,
&epqslot_candidate, tmresult, tmfd))
return false;
/*
@@ -2800,6 +2810,7 @@ ExecARDeleteTriggers(EState *estate,
tupleid,
LockTupleExclusive,
slot,
false,
NULL,
NULL,
NULL);
@@ -2944,7 +2955,8 @@ ExecBRUpdateTriggers(EState *estate, EPQState *epqstate,
HeapTuple fdw_trigtuple,
TupleTableSlot *newslot,
TM_Result *tmresult,
TM_FailureData *tmfd)
TM_FailureData *tmfd,
bool is_merge_update)
{
TriggerDesc *trigdesc = relinfo->ri_TrigDesc;
TupleTableSlot *oldslot = ExecGetTriggerOldSlot(estate, relinfo);
@@ -2965,10 +2977,17 @@ ExecBRUpdateTriggers(EState *estate, EPQState *epqstate,
{
TupleTableSlot *epqslot_candidate = NULL;
/* get a copy of the on-disk tuple we are planning to update */
/*
* Get a copy of the on-disk tuple we are planning to update. In
* general, if the tuple has been concurrently updated, we should
* recheck it using EPQ. However, if this is a MERGE UPDATE action,
* we skip this EPQ recheck and leave it to the caller (it must do
* additional rechecking, and might end up executing a different
* action entirely).
*/
if (!GetTupleForTrigger(estate, epqstate, relinfo, tupleid,
lockmode, oldslot, &epqslot_candidate,
tmresult, tmfd))
lockmode, oldslot, !is_merge_update,
&epqslot_candidate, tmresult, tmfd))
return false; /* cancel the update action */
/*
@@ -3142,6 +3161,7 @@ ExecARUpdateTriggers(EState *estate, ResultRelInfo *relinfo,
tupleid,
LockTupleExclusive,
oldslot,
false,
NULL,
NULL,
NULL);
@@ -3298,6 +3318,7 @@ GetTupleForTrigger(EState *estate,
ItemPointer tid,
LockTupleMode lockmode,
TupleTableSlot *oldslot,
bool do_epq_recheck,
TupleTableSlot **epqslot,
TM_Result *tmresultp,
TM_FailureData *tmfdp)
@@ -3357,17 +3378,11 @@ GetTupleForTrigger(EState *estate,
if (tmfd.traversed)
{
/*
* Recheck the tuple using EPQ. For MERGE, we leave this
* to the caller (it must do additional rechecking, and
* might end up executing a different action entirely).
* Recheck the tuple using EPQ, if requested. Otherwise,
* just return that it was concurrently updated.
*/
if (estate->es_plannedstmt->commandType == CMD_MERGE)
if (do_epq_recheck)
{
if (tmresultp)
*tmresultp = TM_Updated;
return false;
}
*epqslot = EvalPlanQual(epqstate,
relation,
relinfo->ri_RangeTableIndex,
@@ -3383,6 +3398,13 @@ GetTupleForTrigger(EState *estate,
return false;
}
}
else
{
if (tmresultp)
*tmresultp = TM_Updated;
return false;
}
}
break;
case TM_Updated:

4
src/backend/executor/execReplication.c
View File

@@ -670,7 +670,7 @@ ExecSimpleRelationUpdate(ResultRelInfo *resultRelInfo,
resultRelInfo->ri_TrigDesc->trig_update_before_row)
{
if (!ExecBRUpdateTriggers(estate, epqstate, resultRelInfo,
tid, NULL, slot, NULL, NULL))
tid, NULL, slot, NULL, NULL, false))
skip_tuple = true; /* "do nothing" */
}
@@ -746,7 +746,7 @@ ExecSimpleRelationDelete(ResultRelInfo *resultRelInfo,
resultRelInfo->ri_TrigDesc->trig_delete_before_row)
{
skip_tuple = !ExecBRDeleteTriggers(estate, epqstate, resultRelInfo,
tid, NULL, NULL, NULL, NULL);
tid, NULL, NULL, NULL, NULL, false);
}
if (!skip_tuple)

6
src/backend/executor/nodeModifyTable.c
View File

@@ -1474,7 +1474,8 @@ ExecDeletePrologue(ModifyTableContext *context, ResultRelInfo *resultRelInfo,
return ExecBRDeleteTriggers(context->estate, context->epqstate,
resultRelInfo, tupleid, oldtuple,
epqreturnslot, result, &context->tmfd);
epqreturnslot, result, &context->tmfd,
context->mtstate->operation == CMD_MERGE);
}
return true;
@@ -2117,7 +2118,8 @@ ExecUpdatePrologue(ModifyTableContext *context, ResultRelInfo *resultRelInfo,
return ExecBRUpdateTriggers(context->estate, context->epqstate,
resultRelInfo, tupleid, oldtuple, slot,
result, &context->tmfd);
result, &context->tmfd,
context->mtstate->operation == CMD_MERGE);
}
return true;

6
src/include/commands/trigger.h
View File

@@ -213,7 +213,8 @@ extern bool ExecBRDeleteTriggers(EState *estate,
HeapTuple fdw_trigtuple,
TupleTableSlot **epqslot,
TM_Result *tmresult,
TM_FailureData *tmfd);
TM_FailureData *tmfd,
bool is_merge_delete);
extern void ExecARDeleteTriggers(EState *estate,
ResultRelInfo *relinfo,
ItemPointer tupleid,
@@ -235,7 +236,8 @@ extern bool ExecBRUpdateTriggers(EState *estate,
HeapTuple fdw_trigtuple,
TupleTableSlot *newslot,
TM_Result *tmresult,
TM_FailureData *tmfd);
TM_FailureData *tmfd,
bool is_merge_update);
extern void ExecARUpdateTriggers(EState *estate,
ResultRelInfo *relinfo,
ResultRelInfo *src_partinfo,

11
src/test/isolation/expected/merge-match-recheck.out
View File

@@ -241,6 +241,7 @@ starting permutation: update_bal1_tg merge_bal_tg c2 select1_tg c1
s2: NOTICE: Update: (1,160,s1,setup) -> (1,50,s1,"setup updated by update_bal1_tg")
step update_bal1_tg: UPDATE target_tg t SET balance = 50, val = t.val || ' updated by update_bal1_tg' WHERE t.key = 1;
step merge_bal_tg:
WITH t AS (
MERGE INTO target_tg t
USING (SELECT 1 as key) s
ON s.key = t.key
@@ -249,11 +250,19 @@ step merge_bal_tg:
WHEN MATCHED AND balance < 200 THEN
UPDATE SET balance = balance * 4, val = t.val || ' when2'
WHEN MATCHED AND balance < 300 THEN
UPDATE SET balance = balance * 8, val = t.val || ' when3';
UPDATE SET balance = balance * 8, val = t.val || ' when3'
RETURNING t.*
)
SELECT * FROM t;
<waiting ...>
step c2: COMMIT;
s1: NOTICE: Update: (1,50,s1,"setup updated by update_bal1_tg") -> (1,100,s1,"setup updated by update_bal1_tg when1")
step merge_bal_tg: <... completed>
key|balance|status|val
---+-------+------+-------------------------------------
1| 100|s1 |setup updated by update_bal1_tg when1
(1 row)
step select1_tg: SELECT * FROM target_tg;
key|balance|status|val
---+-------+------+-------------------------------------

6
src/test/isolation/specs/merge-match-recheck.spec
View File

@@ -99,6 +99,7 @@ step "merge_bal_pa"
}
step "merge_bal_tg"
{
WITH t AS (
MERGE INTO target_tg t
USING (SELECT 1 as key) s
ON s.key = t.key
@@ -107,7 +108,10 @@ step "merge_bal_tg"
WHEN MATCHED AND balance < 200 THEN
UPDATE SET balance = balance * 4, val = t.val || ' when2'
WHEN MATCHED AND balance < 300 THEN
UPDATE SET balance = balance * 8, val = t.val || ' when3';
UPDATE SET balance = balance * 8, val = t.val || ' when3'
RETURNING t.*
)
SELECT * FROM t;
}
step "merge_delete"