pgsql: Make partition-lock-release coding more transparent in BufferAll - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Make partition-lock-release coding more transparent in BufferAll
Date
Msg-id E1asHJ1-0000FD-Bu@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Make partition-lock-release coding more transparent in BufferAlloc().

Coverity complained that oldPartitionLock was possibly dereferenced after
having been set to NULL.  That actually can't happen, because we'd only use
it if (oldFlags & BM_TAG_VALID) is true.  But nonetheless Coverity is
justified in complaining, because at line 1275 we actually overwrite
oldFlags, and then still expect its BM_TAG_VALID bit to be a safe guide to
whether to release the oldPartitionLock.  Thus, the code would be incorrect
if someone else had changed the buffer's BM_TAG_VALID flag meanwhile.
That should not happen, since we hold pin on the buffer throughout this
sequence, but it's starting to look like a rather shaky chain of logic.
And there's no need for such assumptions, because we can simply replace
the (oldFlags & BM_TAG_VALID) tests with (oldPartitionLock != NULL),
which has identical results and makes it plain to all comers that we don't
dereference a null pointer.  A small side benefit is that the range of
liveness of oldFlags is greatly reduced, possibly allowing the compiler
to save a register.

This is just cleanup, not an actual bug fix, so there seems no need
for a back-patch.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/a0382e2d7e330de13e15cea0921a95faa9da3570

Modified Files
--------------
src/backend/storage/buffer/bufmgr.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Further reduce the number of semaphores used under --disable-spi
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <