From 3637c5d4e70cd06c1220c1b9280ba4d7aea8d9bc Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 10 Mar 2013 19:18:49 -0400 Subject: [PATCH] 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). --- src/backend/executor/nodeModifyTable.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c index c9171a4da8..15279f62d2 100644 --- a/src/backend/executor/nodeModifyTable.c +++ b/src/backend/executor/nodeModifyTable.c @@ -807,6 +807,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); -- GitLab