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

Commit1f9534b

Browse files
committed
Fix torn-page, unlogged xid and further risks from heap_update().
When heap_update needs to look for a page for the new tuple version,because the current one doesn't have sufficient free space, or whencolumns have to be processed by the tuple toaster, it has to release thelock on the old page during that. Otherwise there'd be lock ordering andlock nesting issues.To avoid concurrent sessions from trying to update / delete / lock thetuple while the page's content lock is released, the tuple's xmax is setto the current session's xid.That unfortunately was done without any WAL logging, thereby violatingthe rule that no XIDs may appear on disk, without an according WALrecord. If the database were to crash / fail over when the page levellock is released, and some activity lead to the page being written outto disk, the xid could end up being reused; potentially leading to therow becoming invisible.There might be additional risks by not having t_ctid point at the tupleitself, without having set the appropriate lock infomask fields.To fix, compute the appropriate xmax/infomask combination for lockingthe tuple, and perform WAL logging using the existing XLOG_HEAP_LOCKrecord. That allows the fix to be backpatched.This issue has existed for a long time. There appears to have beenpartial attempts at preventing dangers, but these never have fully beenimplemented, and were removed a long time ago, in1191916 (cf. HEAP_XMAX_UNLOGGED).In master / 9.6, there's an additional issue, namely that thevisibilitymap's freeze bit isn't reset at that point yet. Since that's anew issue, introduced only ina892234, that'll be fixed in aseparate commit.Author: Masahiko Sawada and Andres FreundReported-By: Different aspects by Thomas Munro, Noah Misch, and othersDiscussion: CAEepm=3fWAbWryVW9swHyLTY4sXVf0xbLvXqOwUoDiNCx9mBjQ@mail.gmail.comBackpatch: 9.1/all supported versions
1 parentb33e81c commit1f9534b

File tree

1 file changed

+73
-23
lines changed

1 file changed

+73
-23
lines changed

‎src/backend/access/heap/heapam.c

Lines changed: 73 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -3232,8 +3232,7 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
32323232
newbuf,
32333233
vmbuffer=InvalidBuffer,
32343234
vmbuffer_new=InvalidBuffer;
3235-
boolneed_toast,
3236-
already_marked;
3235+
boolneed_toast;
32373236
Sizenewtupsize,
32383237
pagefree;
32393238
boolhave_tuple_lock= false;
@@ -3675,8 +3674,8 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
36753674
* on the same page as the old, then we need to release the content lock
36763675
* (but not the pin!) on the old tuple's buffer while we are off doing
36773676
* TOAST and/or table-file-extension work. We must mark the old tuple to
3678-
* show that it'salready being updated, else other processes may try to
3679-
*update itthemselves.
3677+
* show that it'slocked, else other processes may try to update it
3678+
* themselves.
36803679
*
36813680
* We need to invoke the toaster if there are already any out-of-line
36823681
* toasted values present, or if the new tuple is over-threshold.
@@ -3700,19 +3699,73 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
37003699

37013700
if (need_toast||newtupsize>pagefree)
37023701
{
3702+
TransactionIdxmax_lock_old_tuple;
3703+
uint16infomask_lock_old_tuple,
3704+
infomask2_lock_old_tuple;
3705+
3706+
/*
3707+
* To prevent concurrent sessions from updating the tuple, we have to
3708+
* temporarily mark it locked, while we release the lock.
3709+
*
3710+
* To satisfy the rule that any xid potentially appearing in a buffer
3711+
* written out to disk, we unfortunately have to WAL log this
3712+
* temporary modification. We can reuse xl_heap_lock for this
3713+
* purpose. If we crash/error before following through with the
3714+
* actual update, xmax will be of an aborted transaction, allowing
3715+
* other sessions to proceed.
3716+
*/
3717+
3718+
/*
3719+
* Compute xmax / infomask appropriate for locking the tuple. This has
3720+
* to be done separately from the lock, because the potentially
3721+
* created multixact would otherwise be wrong.
3722+
*/
3723+
compute_new_xmax_infomask(HeapTupleHeaderGetRawXmax(oldtup.t_data),
3724+
oldtup.t_data->t_infomask,
3725+
oldtup.t_data->t_infomask2,
3726+
xid,*lockmode, false,
3727+
&xmax_lock_old_tuple,&infomask_lock_old_tuple,
3728+
&infomask2_lock_old_tuple);
3729+
3730+
Assert(HEAP_XMAX_IS_LOCKED_ONLY(infomask_lock_old_tuple));
3731+
3732+
START_CRIT_SECTION();
3733+
37033734
/* Clear obsolete visibility flags ... */
37043735
oldtup.t_data->t_infomask &= ~(HEAP_XMAX_BITS |HEAP_MOVED);
37053736
oldtup.t_data->t_infomask2 &= ~HEAP_KEYS_UPDATED;
37063737
HeapTupleClearHotUpdated(&oldtup);
37073738
/* ... and store info about transaction updating this tuple */
3708-
Assert(TransactionIdIsValid(xmax_old_tuple));
3709-
HeapTupleHeaderSetXmax(oldtup.t_data,xmax_old_tuple);
3710-
oldtup.t_data->t_infomask |=infomask_old_tuple;
3711-
oldtup.t_data->t_infomask2 |=infomask2_old_tuple;
3739+
Assert(TransactionIdIsValid(xmax_lock_old_tuple));
3740+
HeapTupleHeaderSetXmax(oldtup.t_data,xmax_lock_old_tuple);
3741+
oldtup.t_data->t_infomask |=infomask_lock_old_tuple;
3742+
oldtup.t_data->t_infomask2 |=infomask2_lock_old_tuple;
37123743
HeapTupleHeaderSetCmax(oldtup.t_data,cid,iscombo);
3713-
/* temporarily make it look not-updated */
3744+
3745+
/* temporarily make it look not-updated, but locked */
37143746
oldtup.t_data->t_ctid=oldtup.t_self;
3715-
already_marked= true;
3747+
3748+
MarkBufferDirty(buffer);
3749+
3750+
if (RelationNeedsWAL(relation))
3751+
{
3752+
xl_heap_lockxlrec;
3753+
XLogRecPtrrecptr;
3754+
3755+
XLogBeginInsert();
3756+
XLogRegisterBuffer(0,buffer,REGBUF_STANDARD);
3757+
3758+
xlrec.offnum=ItemPointerGetOffsetNumber(&oldtup.t_self);
3759+
xlrec.locking_xid=xmax_lock_old_tuple;
3760+
xlrec.infobits_set=compute_infobits(oldtup.t_data->t_infomask,
3761+
oldtup.t_data->t_infomask2);
3762+
XLogRegisterData((char*)&xlrec,SizeOfHeapLock);
3763+
recptr=XLogInsert(RM_HEAP_ID,XLOG_HEAP_LOCK);
3764+
PageSetLSN(page,recptr);
3765+
}
3766+
3767+
END_CRIT_SECTION();
3768+
37163769
LockBuffer(buffer,BUFFER_LOCK_UNLOCK);
37173770

37183771
/*
@@ -3783,7 +3836,6 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
37833836
else
37843837
{
37853838
/* No TOAST work needed, and it'll fit on same page */
3786-
already_marked= false;
37873839
newbuf=buffer;
37883840
heaptup=newtup;
37893841
}
@@ -3870,18 +3922,16 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
38703922

38713923
RelationPutHeapTuple(relation,newbuf,heaptup, false);/* insert new tuple */
38723924

3873-
if (!already_marked)
3874-
{
3875-
/* Clear obsolete visibility flags ... */
3876-
oldtup.t_data->t_infomask &= ~(HEAP_XMAX_BITS |HEAP_MOVED);
3877-
oldtup.t_data->t_infomask2 &= ~HEAP_KEYS_UPDATED;
3878-
/* ... and store info about transaction updating this tuple */
3879-
Assert(TransactionIdIsValid(xmax_old_tuple));
3880-
HeapTupleHeaderSetXmax(oldtup.t_data,xmax_old_tuple);
3881-
oldtup.t_data->t_infomask |=infomask_old_tuple;
3882-
oldtup.t_data->t_infomask2 |=infomask2_old_tuple;
3883-
HeapTupleHeaderSetCmax(oldtup.t_data,cid,iscombo);
3884-
}
3925+
3926+
/* Clear obsolete visibility flags, possibly set by ourselves above... */
3927+
oldtup.t_data->t_infomask &= ~(HEAP_XMAX_BITS |HEAP_MOVED);
3928+
oldtup.t_data->t_infomask2 &= ~HEAP_KEYS_UPDATED;
3929+
/* ... and store info about transaction updating this tuple */
3930+
Assert(TransactionIdIsValid(xmax_old_tuple));
3931+
HeapTupleHeaderSetXmax(oldtup.t_data,xmax_old_tuple);
3932+
oldtup.t_data->t_infomask |=infomask_old_tuple;
3933+
oldtup.t_data->t_infomask2 |=infomask2_old_tuple;
3934+
HeapTupleHeaderSetCmax(oldtup.t_data,cid,iscombo);
38853935

38863936
/* record address of new tuple in t_ctid of old one */
38873937
oldtup.t_data->t_ctid=heaptup->t_self;

0 commit comments

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