]> granicus.if.org Git - postgresql/commit
Make partition-lock-release coding more transparent in BufferAlloc().
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 18 Apr 2016 22:05:56 +0000 (18:05 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 18 Apr 2016 22:05:56 +0000 (18:05 -0400)
commita0382e2d7e330de13e15cea0921a95faa9da3570
tree5b8759113f2cf07cfa320b61635e871cb4565199
parent75c24d0f7491f77dfbc0acdf6c18439f288353ef
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.
src/backend/storage/buffer/bufmgr.c