Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit e118822

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 21aa47d commit e118822

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
@@ -1542,6 +1542,7 @@ AbortStrongLockAcquire(void)
15421542
fasthashcode = FastPathStrongLockHashPartition(locallock->hashcode);
15431543
Assert(locallock->holdsStrongLockCount == TRUE);
15441544
SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
1545+
Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
15451546
FastPathStrongRelationLocks->count[fasthashcode]--;
15461547
locallock->holdsStrongLockCount = FALSE;
15471548
StrongLockInProgress = NULL;
@@ -2952,6 +2953,7 @@ LockRefindAndRelease(LockMethod lockMethodTable, PGPROC *proc,
29522953
uint32 fasthashcode = FastPathStrongLockHashPartition(hashcode);
29532954

29542955
SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
2956+
Assert(FastPathStrongRelationLocks->count[fasthashcode] > 0);
29552957
FastPathStrongRelationLocks->count[fasthashcode]--;
29562958
SpinLockRelease(&FastPathStrongRelationLocks->mutex);
29572959
}

0 commit comments

Comments
 (0)