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

Commit 462a2f1

Browse files
committed
Fix RBM_ZERO_AND_LOCK mode to not acquire lock on local buffers.
Commit 81c4508 introduced a new RBM_ZERO_AND_LOCK mode to ReadBuffer, which takes a lock on the buffer before zeroing it. However, you cannot take a lock on a local buffer, and you got a segfault instead. The version of that patch committed to master included a check for !isLocalBuf, and therefore didn't crash, but oddly I missed that in the back-patched versions. This patch adds that check to the back-branches too. RBM_ZERO_AND_LOCK mode is only used during WAL replay, and in hash indexes. WAL replay only deals with shared buffers, so the only way to trigger the bug is with a temporary hash index. Reported by Artem Ignatyev, analysis by Tom Lane.
1 parent 4d3d971 commit 462a2f1

File tree

1 file changed

+2
-1
lines changed

1 file changed

+2
-1
lines changed

src/backend/storage/buffer/bufmgr.c

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -515,7 +515,8 @@ ReadBuffer_common(SMgrRelation smgr, char relpersistence, ForkNumber forkNum,
515515
* (Note that we cannot use LockBuffer() of LockBufferForCleanup() here,
516516
* because they assert that the buffer is already valid.)
517517
*/
518-
if (mode == RBM_ZERO_AND_LOCK || mode == RBM_ZERO_AND_CLEANUP_LOCK)
518+
if ((mode == RBM_ZERO_AND_LOCK || mode == RBM_ZERO_AND_CLEANUP_LOCK) &&
519+
!isLocalBuf)
519520
LWLockAcquire(bufHdr->content_lock, LW_EXCLUSIVE);
520521

521522
if (isLocalBuf)

0 commit comments

Comments
 (0)