8000 Avoid improbable PANIC during heap_update. · postgrespro/postgres@37e7654 · GitHub
[go: up one dir, main page]
Skip to content

Commit 37e7654

Browse files
tglsfdctglsfdc
committed
Avoid improbable PANIC during heap_update.
heap_update needs to clear any existing "all visibl 8000 e" flag on the old tuple's page (and on the new page too, if different). Per coding rules, to do this it must acquire pin on the appropriate visibility-map page while not holding exclusive buffer lock; which creates a race condition since someone else could set the flag whenever we're not holding the buffer lock. The code is supposed to handle that by re-checking the flag after acquiring buffer lock and retrying if it became set. However, one code path through heap_update itself, as well as one in its subroutine RelationGetBufferForTuple, failed to do this. The end result, in the unlikely event that a concurrent VACUUM did set the flag while 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 VACUUM changes that added code paths that could set the all-visible flag while holding only exclusive buffer lock. Previously, the flag was (usually?) set only after doing LockBufferForCleanup, which would insist on buffer pin count zero, thus preventing the flag from becoming set partway through heap_update. However, it's clear that it's heap_update not VACUUM that's at fault here. What's less clear is whether there is any hazard from these bugs in released branches. heap_update is certainly violating API expectations, but if there is no code path that can set all-visible without a cleanup lock then it's only a latent bug. That's not 100% certain though, besides which we should worry about extensions or future back-patch fixes that could introduce such code paths. I chose to back-patch to v12. Fixing RelationGetBufferForTuple before that would require also back-patching portions of older fixes (notably 0d1fe9f), which is more code churn than seems prudent to fix a hypothetical issue. Discussion: https://postgr.es/m/2247102.1618008027@sss.pgh.pa.us
1 parent 1388119 commit 37e7654

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
@@ -3445,7 +3445,7 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
34453445
* overhead would be unchanged, that doesn't seem necessarily
34463446
* worthwhile.
34473447
*/
3448-
if (PageIsAllVisible(BufferGetPage(buffer)) &&
3448+
if (PageIsAllVisible(page) &&
34493449
visibilitymap_clear(relation, block, vmbuffer,
34503450
VISIBILITYMAP_ALL_FROZEN))
34513451
cleared_all_frozen = true;
@@ -3507,36 +3507,46 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
35073507
* first". To implement this, we must do RelationGetBufferForTuple
35083508
* while not holding the lock on the old page, and we must rely on it
35093509
* to get the locks on both pages in the correct order.
3510+
*
3511+
* Another consideration is that we need visibility map page pin(s) if
3512+
* we will have to clear the all-visible flag on either page. If we
3513+
* call RelationGetBufferForTuple, we rely on it to acquire any such
3514+
* pins; but if we don't, we have to handle that here. Hence we need
3515+
* a loop.
35103516
*/
3511-
if (newtupsize > pagefree)
3512-
{
3513-
/* Assume there's no chance to put heaptup on same page. */
3514-
newbuf = RelationGetBufferForTuple(relation, heaptup->t_len,
3515-
buffer, 0, NULL,
3516-
&vmbuffer_new, &vmbuffer);
3517-
}
3518-
else
3517+
for (;;)
35193518
{
3519+
if (newtupsize > pagefree)
3520+
{
3521+
/* It doesn't fit, must use RelationGetBufferForTuple. */
3522+
newbuf = RelationGetBufferForTuple(relation, heaptup->t_len,
3523+
buffer, 0, NULL,
3524+
&vmbuffer_new, &vmbuffer);
3525+
/* We're all done. */
3526+
break;
3527+
}
3528+
/* Acquire VM page pin if needed and we don't have it. */
3529+
if (vmbuffer == InvalidBuffer && PageIsAllVisible(page))
3530+
visibilitymap_pin(relation, block, &vmbuffer);
35203531
/* Re-acquire the lock on the old tuple's page. */
35213532
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
35223533
/* Re-check using the up-to-date free space */
35233534
pagefree = PageGetHeapFreeSpace(page);
3524-
if (newtupsize > pagefree)
3535+
if (newtupsize > pagefree ||
3536+
(vmbuffer == InvalidBuffer && PageIsAllVisible(page)))
35253537
{
35263538
/*
3527-
* Rats, it doesn't fit anymore. We must now unlock and
3528-
* relock to avoid deadlock. Fortunately, this path should
3529-
* seldom be taken.
3539+
* Rats, it doesn't fit anymore, or somebody just now set the
3540+
* all-visible flag. We must now unlock and loop to avoid
3541+
* deadlock. Fortunately, this path should seldom be taken.
35303542
*/
35313543
LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
3532-
newbuf = RelationGetBufferForTuple(relation, heaptup->t_len,
3533-
buffer, 0, NULL,
3534-
&vmbuffer_new, &vmbuffer);
35353544
}
35363545
else
35373546
{
3538-
/* OK, it fits here, so we're done. */
3547+
/* We're all done. */
35393548
newbuf = buffer;
3549+
break;
35403550
}
35413551
}
35423552
}

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

Lines changed: 18 additions & 6 deletions
< 8000 td data-grid-cell-id="diff-7aea5e33b678ce7f9a894aed38cbe02a1e61238595011c56ca877a36923ca495-289-293-1" data-selected="false" role="gridcell" style="background-color:var(--diffBlob-additionNum-bgColor, var(--diffBlob-addition-bgColor-num));text-align:center" tabindex="-1" valign="top" class="focusable-grid-cell diff-line-number position-relative left-side">293
Original file line numberDiff line numberDiff line change
@@ -284,9 +284,13 @@ RelationAddExtraBlocks(Relation relation, BulkInsertState bistate)
284284
* happen if space is freed in that page after heap_update finds there's not
285285
* enough there). In that case, the page will be pinned and locked only once.
286286
*
287-
* For the vmbuffer and vmbuffer_other arguments, we avoid deadlock by
288-
* locking them only after locking the corresponding heap page, and taking
289-
* no further lwlocks while they are locked.
287+
* We also handle the possibility that the all-visible flag will need to be
288+
* cleared on one or both pages. If so, pin on the associated visibility map
289+
* page must be acquired before acquiring buffer lock(s), to avoid possibly
290+
* doing I/O while holding buffer locks. The pins are passed back to the
291+
* caller using the input-output arguments vmbuffer and vmbuffer_other.
292+
* Note that in some cases the caller might have already acquired such pins,
+
* which is indicated by these arguments not being InvalidBuffer on entry.
290294
*
291295
* We normally use FSM to help us find free space. However,
292296
* if HEAP_INSERT_SKIP_FSM is specified, we just append a new empty page to
@@ -631,6 +635,8 @@ RelationGetBufferForTuple(Relation relation, Size len,
631635
if (otherBuffer != InvalidBuffer)
632636
{
633637
Assert(otherBuffer != buffer);
638+
targetBlock = BufferGetBlockNumber(buffer);
639+
Assert(targetBlock > otherBlock);
634640

635641
if (unlikely(!ConditionalLockBuffer(otherBuffer)))
636642
{
@@ -639,10 +645,16 @@ RelationGetBufferForTuple(Relation relation, Size len,
639645
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
640646

641647
/*
642-
* Because the buffer was unlocked for a while, it's possible,
643-
* although unlikely, that the page was filled. If so, just retry
644-
* from start.
648+
* Because the buffers were unlocked for a while, it's possible,
649+
* although unlikely, that an all-visible flag became set or that
650+
* somebody used up the available space in the new page. We can
651+
* use GetVisibilityMapPins to deal with the first case. In the
652+
* second case, just retry from start.
645653
*/
654+
GetVisibilityMapPins(relation, otherBuffer, buffer,
655+
otherBlock, targetBlock, vmbuffer_other,
656+
vmbuffer);
657+
646658
if (len > PageGetHeapFreeSpace(page))
647659
{
648660
LockBuffer(otherBuffer, BUFFER_LOCK_UNLOCK);

0 commit comments

Comments
 (0)
0