Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 624f155

Browse files
committed
heap_update() must recheck tuple after unlocking and relocking buffer.
Bug found by Alvaro Herrera, fix suggested by Heikki Linnakangas and reviewed by Tom Lane.
1 parent 269c5dd commit 624f155

File tree

1 file changed

+4
-1
lines changed

1 file changed

+4
-1
lines changed

src/backend/access/heap/heapam.c

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2645,13 +2645,16 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
26452645
* visible while we were busy locking the buffer, or during some subsequent
26462646
* window during which we had it unlocked, we'll have to unlock and
26472647
* re-lock, to avoid holding the buffer lock across an I/O. That's a bit
2648-
* unfortunate, but hopefully shouldn't happen often.
2648+
* unfortunate, esepecially since we'll now have to recheck whether the
2649+
* tuple has been locked or updated under us, but hopefully it won't
2650+
* happen very often.
26492651
*/
26502652
if (vmbuffer == InvalidBuffer && PageIsAllVisible(page))
26512653
{
26522654
LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
26532655
visibilitymap_pin(relation, block, &vmbuffer);
26542656
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
2657+
goto l2;
26552658
}
26562659

26572660
/*

0 commit comments

Comments
 (0)