Fix race condition in DELETE RETURNING.

When RETURNING is specified, ExecDelete would return a virtual-tuple slot
that could contain pointers into an already-unpinned disk buffer.  Another
process could change the buffer contents before we get around to using the
data, resulting in garbage results or even a crash.  This seems of fairly
low probability, which may explain why there are no known field reports of
the problem, but it's definitely possible.  Fix by forcing the result slot
to be "materialized" before we release pin on the disk buffer.

Back-patch to 9.0; in earlier branches there is no bug because
ExecProcessReturning sent the tuple to the destination immediately.  Also,
this is already fixed in HEAD as part of the writable-foreign-tables patch
(where the fix is necessary for DELETE RETURNING to work at all with
postgres_fdw).

diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index a7bce75f0cb63c78d59306261bae5dd093a120fc..8d51a27ad6d494c419dd4b452fe088db60b1d23c 100644 (file)
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -440,6 +440,12 @@ ldelete:;
                rslot = ExecProcessReturning(resultRelInfo->ri_projectReturning,
                                                                         slot, planSlot);
 
+               /*
+                * Before releasing the target tuple again, make sure rslot has a
+                * local copy of any pass-by-reference values.
+                */
+               ExecMaterializeSlot(rslot);
+
                ExecClearTuple(slot);
                if (BufferIsValid(delbuffer))
                        ReleaseBuffer(delbuffer);