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

Commit8d4bb31

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 parent1dd9238 commit8d4bb31

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
@@ -394,6 +394,12 @@ ldelete:;
394394
rslot=ExecProcessReturning(resultRelInfo->ri_projectReturning,
395395
slot,planSlot);
396396

397+
/*
398+
* Before releasing the target tuple again, make sure rslot has a
399+
* local copy of any pass-by-reference values.
400+
*/
401+
ExecMaterializeSlot(rslot);
402+
397403
ExecClearTuple(slot);
398404
ReleaseBuffer(delbuffer);
399405

0 commit comments

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