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

Commit34f581c

Browse files
committed
Avoid improbable PANIC during heap_update.
heap_update needs to clear any existing "all visible" flag onthe old tuple's page (and on the new page too, if different).Per coding rules, to do this it must acquire pin on the appropriatevisibility-map page while not holding exclusive buffer lock;which creates a race condition since someone else could set theflag whenever we're not holding the buffer lock. The code issupposed to handle that by re-checking the flag after acquiringbuffer lock and retrying if it became set. However, one codepath through heap_update itself, as well as one in its subroutineRelationGetBufferForTuple, failed to do this. The end result,in the unlikely event that a concurrent VACUUM did set the flagwhile we're transiently not holding lock, is a non-recurring"PANIC: wrong buffer passed to visibilitymap_clear" failure.This has been seen a few times in the buildfarm since recent VACUUMchanges that added code paths that could set the all-visible flagwhile holding only exclusive buffer lock. Previously, the flagwas (usually?) set only after doing LockBufferForCleanup, whichwould insist on buffer pin count zero, thus preventing the flagfrom becoming set partway through heap_update. However, it'sclear that it's heap_update not VACUUM that's at fault here.What's less clear is whether there is any hazard from these bugsin released branches. heap_update is certainly violating APIexpectations, but if there is no code path that can set all-visiblewithout a cleanup lock then it's only a latent bug. That's not100% certain though, besides which we should worry about extensionsor future back-patch fixes that could introduce such code paths.I chose to back-patch to v12. Fixing RelationGetBufferForTuplebefore that would require also back-patching portions of olderfixes (notably0d1fe9f), which is more code churn than seemsprudent to fix a hypothetical issue.Discussion:https://postgr.es/m/2247102.1618008027@sss.pgh.pa.us
1 parent5fe83ad commit34f581c

File tree

2 files changed

+45
-23
lines changed

2 files changed

+45
-23
lines changed

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

Lines changed: 27 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -3784,7 +3784,7 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
37843784
* overhead would be unchanged, that doesn't seem necessarily
37853785
* worthwhile.
37863786
*/
3787-
if (PageIsAllVisible(BufferGetPage(buffer))&&
3787+
if (PageIsAllVisible(page)&&
37883788
visibilitymap_clear(relation,block,vmbuffer,
37893789
VISIBILITYMAP_ALL_FROZEN))
37903790
cleared_all_frozen= true;
@@ -3846,36 +3846,46 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
38463846
* first". To implement this, we must do RelationGetBufferForTuple
38473847
* while not holding the lock on the old page, and we must rely on it
38483848
* to get the locks on both pages in the correct order.
3849+
*
3850+
* Another consideration is that we need visibility map page pin(s) if
3851+
* we will have to clear the all-visible flag on either page. If we
3852+
* call RelationGetBufferForTuple, we rely on it to acquire any such
3853+
* pins; but if we don't, we have to handle that here. Hence we need
3854+
* a loop.
38493855
*/
3850-
if (newtupsize>pagefree)
3851-
{
3852-
/* Assume there's no chance to put heaptup on same page. */
3853-
newbuf=RelationGetBufferForTuple(relation,heaptup->t_len,
3854-
buffer,0,NULL,
3855-
&vmbuffer_new,&vmbuffer);
3856-
}
3857-
else
3856+
for (;;)
38583857
{
3858+
if (newtupsize>pagefree)
3859+
{
3860+
/* It doesn't fit, must use RelationGetBufferForTuple. */
3861+
newbuf=RelationGetBufferForTuple(relation,heaptup->t_len,
3862+
buffer,0,NULL,
3863+
&vmbuffer_new,&vmbuffer);
3864+
/* We're all done. */
3865+
break;
3866+
}
3867+
/* Acquire VM page pin if needed and we don't have it. */
3868+
if (vmbuffer==InvalidBuffer&&PageIsAllVisible(page))
3869+
visibilitymap_pin(relation,block,&vmbuffer);
38593870
/* Re-acquire the lock on the old tuple's page. */
38603871
LockBuffer(buffer,BUFFER_LOCK_EXCLUSIVE);
38613872
/* Re-check using the up-to-date free space */
38623873
pagefree=PageGetHeapFreeSpace(page);
3863-
if (newtupsize>pagefree)
3874+
if (newtupsize>pagefree||
3875+
(vmbuffer==InvalidBuffer&&PageIsAllVisible(page)))
38643876
{
38653877
/*
3866-
* Rats, it doesn't fit anymore. We must nowunlock and
3867-
*relock to avoid deadlock. Fortunately, this path should
3868-
* seldom be taken.
3878+
* Rats, it doesn't fit anymore, or somebody just nowset the
3879+
*all-visible flag. We must now unlock and loop to avoid
3880+
*deadlock. Fortunately, this path shouldseldom be taken.
38693881
*/
38703882
LockBuffer(buffer,BUFFER_LOCK_UNLOCK);
3871-
newbuf=RelationGetBufferForTuple(relation,heaptup->t_len,
3872-
buffer,0,NULL,
3873-
&vmbuffer_new,&vmbuffer);
38743883
}
38753884
else
38763885
{
3877-
/*OK, it fits here, so we're done. */
3886+
/*We're all done. */
38783887
newbuf=buffer;
3888+
break;
38793889
}
38803890
}
38813891
}

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

Lines changed: 18 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -293,9 +293,13 @@ RelationAddExtraBlocks(Relation relation, BulkInsertState bistate)
293293
*happen if space is freed in that page after heap_update finds there's not
294294
*enough there). In that case, the page will be pinned and locked only once.
295295
*
296-
*For the vmbuffer and vmbuffer_other arguments, we avoid deadlock by
297-
*locking them only after locking the corresponding heap page, and taking
298-
*no further lwlocks while they are locked.
296+
*We also handle the possibility that the all-visible flag will need to be
297+
*cleared on one or both pages. If so, pin on the associated visibility map
298+
*page must be acquired before acquiring buffer lock(s), to avoid possibly
299+
*doing I/O while holding buffer locks. The pins are passed back to the
300+
*caller using the input-output arguments vmbuffer and vmbuffer_other.
301+
*Note that in some cases the caller might have already acquired such pins,
302+
*which is indicated by these arguments not being InvalidBuffer on entry.
299303
*
300304
*We normally use FSM to help us find free space. However,
301305
*if HEAP_INSERT_SKIP_FSM is specified, we just append a new empty page to
@@ -666,6 +670,8 @@ RelationGetBufferForTuple(Relation relation, Size len,
666670
if (otherBuffer!=InvalidBuffer)
667671
{
668672
Assert(otherBuffer!=buffer);
673+
targetBlock=BufferGetBlockNumber(buffer);
674+
Assert(targetBlock>otherBlock);
669675

670676
if (unlikely(!ConditionalLockBuffer(otherBuffer)))
671677
{
@@ -674,10 +680,16 @@ RelationGetBufferForTuple(Relation relation, Size len,
674680
LockBuffer(buffer,BUFFER_LOCK_EXCLUSIVE);
675681

676682
/*
677-
* Because the buffer was unlocked for a while, it's possible,
678-
* although unlikely, that the page was filled. If so, just retry
679-
* from start.
683+
* Because the buffers were unlocked for a while, it's possible,
684+
* although unlikely, that an all-visible flag became set or that
685+
* somebody used up the available space in the new page. We can
686+
* use GetVisibilityMapPins to deal with the first case. In the
687+
* second case, just retry from start.
680688
*/
689+
GetVisibilityMapPins(relation,otherBuffer,buffer,
690+
otherBlock,targetBlock,vmbuffer_other,
691+
vmbuffer);
692+
681693
if (len>PageGetHeapFreeSpace(page))
682694
{
683695
LockBuffer(otherBuffer,BUFFER_LOCK_UNLOCK);

0 commit comments

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