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

Commitc7edaee

Browse files
committed
Prevent access to an unpinned buffer in BEFORE ROW UPDATE triggers.
When ExecBRUpdateTriggers switches to a new target tuple as a resultof the EvalPlanQual logic, it must form a new proposed update tuple.Since commit86dc900, that tuple (the result ofExecGetUpdateNewTuple) has been a virtual tuple that might containpointers to by-ref fields of the new target tuple (in "oldslot").However, immediately after that we materialize oldslot, causing it todrop its buffer pin, whereupon the by-ref pointers are unsafe to use.This is a live bug only when the new target tuple is in a differentpage than the original target tuple, since we do still hold a pin onthe original one. (Before86dc900, there was no bug because theEPQ plantree would hold a pin on the new target tuple; but now that'snot assured.) To fix, forcibly materialize the new tuple before wematerialize oldslot. This costs nothing since we would have done thatshortly anyway.The real-world impact of this is probably minimal. A visible failurecould occur if the new target tuple's buffer were recycled for someother page in the short interval before we materialize newslot withinthe trigger-calling loop; but that's quite unlikely given that we'djust touched that page. There's a larger hazard that some otherprocess could prune and repack that page within the window. We havelock on the new target tuple, but that wouldn't prevent it being movedon the page.Alexander Lakhin and Tom Lane, per bug #17798 from Alexander Lakhin.Back-patch to v14 where86dc900 came in.Discussion:https://postgr.es/m/17798-0907404928dcf0dd@postgresql.org
1 parent7ceeb57 commitc7edaee

File tree

1 file changed

+23
-5
lines changed

1 file changed

+23
-5
lines changed

‎src/backend/commands/trigger.c

Lines changed: 23 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -2790,10 +2790,6 @@ ExecBRUpdateTriggers(EState *estate, EPQState *epqstate,
27902790
* received in newslot. Neither we nor our callers have any further
27912791
* interest in the passed-in tuple, so it's okay to overwrite newslot
27922792
* with the newer data.
2793-
*
2794-
* (Typically, newslot was also generated by ExecGetUpdateNewTuple, so
2795-
* that epqslot_clean will be that same slot and the copy step below
2796-
* is not needed.)
27972793
*/
27982794
if (epqslot_candidate!=NULL)
27992795
{
@@ -2802,14 +2798,36 @@ ExecBRUpdateTriggers(EState *estate, EPQState *epqstate,
28022798
epqslot_clean=ExecGetUpdateNewTuple(relinfo,epqslot_candidate,
28032799
oldslot);
28042800

2805-
if (newslot!=epqslot_clean)
2801+
/*
2802+
* Typically, the caller's newslot was also generated by
2803+
* ExecGetUpdateNewTuple, so that epqslot_clean will be the same
2804+
* slot and copying is not needed. But do the right thing if it
2805+
* isn't.
2806+
*/
2807+
if (unlikely(newslot!=epqslot_clean))
28062808
ExecCopySlot(newslot,epqslot_clean);
2809+
2810+
/*
2811+
* At this point newslot contains a virtual tuple that may
2812+
* reference some fields of oldslot's tuple in some disk buffer.
2813+
* If that tuple is in a different page than the original target
2814+
* tuple, then our only pin on that buffer is oldslot's, and we're
2815+
* about to release it. Hence we'd better materialize newslot to
2816+
* ensure it doesn't contain references into an unpinned buffer.
2817+
* (We'd materialize it below anyway, but too late for safety.)
2818+
*/
2819+
ExecMaterializeSlot(newslot);
28072820
}
28082821

2822+
/*
2823+
* Here we convert oldslot to a materialized slot holding trigtuple.
2824+
* Neither slot passed to the triggers will hold any buffer pin.
2825+
*/
28092826
trigtuple=ExecFetchSlotHeapTuple(oldslot, true,&should_free_trig);
28102827
}
28112828
else
28122829
{
2830+
/* Put the FDW-supplied tuple into oldslot to unify the cases */
28132831
ExecForceStoreHeapTuple(fdw_trigtuple,oldslot, false);
28142832
trigtuple=fdw_trigtuple;
28152833
}

0 commit comments

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