postgres.git / summary / log / commit / refs

commit    e118822e72486aec32bbbecd3cf7543dbb756c58
Author:   Robert Haas <rhaas@postgresql.org>
Date:     Mon Apr 07 14:59:42 2014 +0000
First released in: 9.4.0, 9.2.9, 9.3.5

    Assert that strong-lock count is >0 everywhere it's decremented.
    
    The one existing assertion of this type has tripped a few times in the
    buildfarm lately, but it's not clear whether the problem is really
    originating there or whether it's leftovers from a trip through one
    of the other two paths that lack a matching assertion.  So add one.
    
    Since the same bug(s) most likely exist(s) in the back-branches also,
    back-patch to 9.2, where the fast-path lock mechanism was added.


 src/backend/storage/lmgr/lock.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index 0f218280090..676b3a49382 100644
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -1542,6 +1542,7 @@ AbortStrongLockAcquire(void)
 	fasthashcode = FastPathStrongLockHashPartition(locallock->hashcode);
 	Assert(locallock->holdsStrongLockCount == TRUE);
 	SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
+	Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
 	FastPathStrongRelationLocks->count[fasthashcode]--;
 	locallock->holdsStrongLockCount = FALSE;
 	StrongLockInProgress = NULL;
@@ -2952,6 +2953,7 @@ LockRefindAndRelease(LockMethod lockMethodTable, PGPROC *proc,
 		uint32		fasthashcode = FastPathStrongLockHashPartition(hashcode);
 
 		SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
+		Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
 		FastPathStrongRelationLocks->count[fasthashcode]--;
 		SpinLockRelease(&FastPathStrongRelationLocks->mutex);
 	}


[parent: 21aa47d0175c]