diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2011-02-21 21:18:30 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2011-02-21 21:18:30 -0500 |
commit | 1487ca0514fe18837f8c2c3f4fcfc37e465c0811 (patch) | |
tree | 6339ebe7f0e26285a43b61aa75ea263ec2e702db /src/backend/commands/trigger.c | |
parent | 69bef7ff79eb33e8a355e79e7fbb5338d1557775 (diff) | |
download | postgresql-1487ca0514fe18837f8c2c3f4fcfc37e465c0811.tar.gz postgresql-1487ca0514fe18837f8c2c3f4fcfc37e465c0811.zip |
Fix dangling-pointer problem in before-row update trigger processing.
ExecUpdate checked for whether ExecBRUpdateTriggers had returned a new
tuple value by seeing if the returned tuple was pointer-equal to the old
one. But the "old one" was in estate->es_junkFilter's result slot, which
would be scribbled on if we had done an EvalPlanQual update in response to
a concurrent update of the target tuple; therefore we were comparing a
dangling pointer to a live one. Given the right set of circumstances we
could get a false match, resulting in not forcing the tuple to be stored in
the slot we thought it was stored in. In the case reported by Maxim Boguk
in bug #5798, this led to "cannot extract system attribute from virtual
tuple" failures when trying to do "RETURNING ctid". I believe there is a
very-low-probability chance of more serious errors, such as generating
incorrect index entries based on the original rather than the
trigger-modified version of the row.
In HEAD, change all of ExecBRInsertTriggers, ExecIRInsertTriggers,
ExecBRUpdateTriggers, and ExecIRUpdateTriggers so that they continue to
have similar APIs. In the back branches I just changed
ExecBRUpdateTriggers, since there is no bug in the ExecBRInsertTriggers
case.
Diffstat (limited to 'src/backend/commands/trigger.c')
-rw-r--r-- | src/backend/commands/trigger.c | 50 |
1 files changed, 41 insertions, 9 deletions
diff --git a/src/backend/commands/trigger.c b/src/backend/commands/trigger.c index 6b360afd19e..e05917e278c 100644 --- a/src/backend/commands/trigger.c +++ b/src/backend/commands/trigger.c @@ -1620,18 +1620,19 @@ ExecASUpdateTriggers(EState *estate, ResultRelInfo *relinfo) false, NULL, NULL); } -HeapTuple +TupleTableSlot * ExecBRUpdateTriggers(EState *estate, ResultRelInfo *relinfo, - ItemPointer tupleid, HeapTuple newtuple, + ItemPointer tupleid, TupleTableSlot *slot, CommandId cid) { TriggerDesc *trigdesc = relinfo->ri_TrigDesc; int ntrigs = trigdesc->n_before_row[TRIGGER_EVENT_UPDATE]; int *tgindx = trigdesc->tg_before_row[TRIGGER_EVENT_UPDATE]; + HeapTuple slottuple = ExecMaterializeSlot(slot); + HeapTuple newtuple = slottuple; TriggerData LocTriggerData; HeapTuple trigtuple; HeapTuple oldtuple; - HeapTuple intuple = newtuple; TupleTableSlot *newSlot; int i; @@ -1640,11 +1641,22 @@ ExecBRUpdateTriggers(EState *estate, ResultRelInfo *relinfo, return NULL; /* - * In READ COMMITTED isolation level it's possible that newtuple was - * changed due to concurrent update. + * In READ COMMITTED isolation level it's possible that target tuple was + * changed due to concurrent update. In that case we have a raw subplan + * output tuple in newSlot, and need to run it through the junk filter to + * produce an insertable tuple. + * + * Caution: more than likely, the passed-in slot is the same as the + * junkfilter's output slot, so we are clobbering the original value of + * slottuple by doing the filtering. This is OK since neither we nor our + * caller have any more interest in the prior contents of that slot. */ if (newSlot != NULL) - intuple = newtuple = ExecRemoveJunk(estate->es_junkFilter, newSlot); + { + slot = ExecFilterJunk(estate->es_junkFilter, newSlot); + slottuple = ExecMaterializeSlot(slot); + newtuple = slottuple; + } LocTriggerData.type = T_TriggerData; LocTriggerData.tg_event = TRIGGER_EVENT_UPDATE | @@ -1667,13 +1679,33 @@ ExecBRUpdateTriggers(EState *estate, ResultRelInfo *relinfo, relinfo->ri_TrigFunctions, relinfo->ri_TrigInstrument, GetPerTupleMemoryContext(estate)); - if (oldtuple != newtuple && oldtuple != intuple) + if (oldtuple != newtuple && oldtuple != slottuple) heap_freetuple(oldtuple); if (newtuple == NULL) - break; + { + heap_freetuple(trigtuple); + return NULL; /* "do nothing" */ + } } heap_freetuple(trigtuple); - return newtuple; + + if (newtuple != slottuple) + { + /* + * Return the modified tuple using the es_trig_tuple_slot. We assume + * the tuple was allocated in per-tuple memory context, and therefore + * will go away by itself. The tuple table slot should not try to + * clear it. + */ + TupleTableSlot *newslot = estate->es_trig_tuple_slot; + TupleDesc tupdesc = RelationGetDescr(relinfo->ri_RelationDesc); + + if (newslot->tts_tupleDescriptor != tupdesc) + ExecSetSlotDescriptor(newslot, tupdesc); + ExecStoreTuple(newtuple, newslot, InvalidBuffer, false); + slot = newslot; + } + return slot; } void |