Skip to content

Commit 74cf802

Browse files
committed
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.
1 parent 53463e2 commit 74cf802

File tree

1 file changed

+2
-0
lines changed
  • src/backend/storage/lmgr

1 file changed

+2
-0
lines changed

src/backend/storage/lmgr/lock.c

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1516,6 +1516,7 @@ AbortStrongLockAcquire(void)
15161516
fasthashcode = FastPathStrongLockHashPartition(locallock->hashcode);
15171517
Assert(locallock->holdsStrongLockCount == TRUE);
15181518
SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
1519+
Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
15191520
FastPathStrongRelationLocks->count[fasthashcode]--;
15201521
locallock->holdsStrongLockCount = FALSE;
15211522
StrongLockInProgress = NULL;
@@ -2882,6 +2883,7 @@ LockRefindAndRelease(LockMethod lockMethodTable, PGPROC *proc,
28822883
uint32 fasthashcode = FastPathStrongLockHashPartition(hashcode);
28832884

28842885
SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
2886+
Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
28852887
FastPathStrongRelationLocks->count[fasthashcode]--;
28862888
SpinLockRelease(&FastPathStrongRelationLocks->mutex);
28872889
}

0 commit comments

Comments
 (0)