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.

diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index fd6cd0647ee195b6259fd71e8307caa9e96d4fcf..682506374feefe47119b8aed65ae850a9d4abe93 100644 (file)
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -1541,6 +1541,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;
@@ -2953,6 +2954,7 @@ LockRefindAndRelease(LockMethod lockMethodTable, PGPROC *proc,
                uint32          fasthashcode = FastPathStrongLockHashPartition(hashcode);
 
                SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
+               Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
                FastPathStrongRelationLocks->count[fasthashcode]--;
                SpinLockRelease(&FastPathStrongRelationLocks->mutex);
        }