Fix RBM_ZERO_AND_LOCK mode to not acquire lock on local buffers.
authorHeikki Linnakangas
Wed, 13 May 2015 06:44:43 +0000 (09:44 +0300)
committerHeikki Linnakangas
Wed, 13 May 2015 07:06:52 +0000 (10:06 +0300)
Commit 81c45081 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.

src/backend/storage/buffer/bufmgr.c

index c5d36a6f70509fd23901d8305f8f7e4e06a5abb4..f9b881ff690e24335b2c88832f116779e4e4ea46 100644 (file)
@@ -511,7 +511,8 @@ ReadBuffer_common(SMgrRelation smgr, char relpersistence, ForkNumber forkNum,
     * (Note that we cannot use LockBuffer() of LockBufferForCleanup() here,
     * because they assert that the buffer is already valid.)
     */
-   if (mode == RBM_ZERO_AND_LOCK || mode == RBM_ZERO_AND_CLEANUP_LOCK)
+   if ((mode == RBM_ZERO_AND_LOCK || mode == RBM_ZERO_AND_CLEANUP_LOCK) &&
+       !isLocalBuf)
        LWLockAcquire(bufHdr->content_lock, LW_EXCLUSIVE);
 
    if (isLocalBuf)