Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitcce7486

Browse files
committed
Fix race condition in DELETE RETURNING.
When RETURNING is specified, ExecDelete would return a virtual-tuple slotthat could contain pointers into an already-unpinned disk buffer. Anotherprocess could change the buffer contents before we get around to using thedata, resulting in garbage results or even a crash. This seems of fairlylow probability, which may explain why there are no known field reports ofthe problem, but it's definitely possible. Fix by forcing the result slotto be "materialized" before we release pin on the disk buffer.Back-patch to 9.0; in earlier branches there is no bug becauseExecProcessReturning 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 withpostgres_fdw).
1 parentef2a82b commitcce7486

File tree

1 file changed

+6
-0
lines changed

1 file changed

+6
-0
lines changed

‎src/backend/executor/nodeModifyTable.c

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -439,6 +439,12 @@ ldelete:;
439439
rslot=ExecProcessReturning(resultRelInfo->ri_projectReturning,
440440
slot,planSlot);
441441

442+
/*
443+
* Before releasing the target tuple again, make sure rslot has a
444+
* local copy of any pass-by-reference values.
445+
*/
446+
ExecMaterializeSlot(rslot);
447+
442448
ExecClearTuple(slot);
443449
if (BufferIsValid(delbuffer))
444450
ReleaseBuffer(delbuffer);

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp