aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/trigger.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2011-02-21 21:18:30 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2011-02-21 21:18:30 -0500
commit1487ca0514fe18837f8c2c3f4fcfc37e465c0811 (patch)
tree6339ebe7f0e26285a43b61aa75ea263ec2e702db /src/backend/commands/trigger.c
parent69bef7ff79eb33e8a355e79e7fbb5338d1557775 (diff)
downloadpostgresql-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.c50
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