mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-02-05 19:09:58 +08:00
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.
This commit is contained in:
parent
b8a721149b
commit
315772e4ec
@ -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);
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user