diff options
| author | Robert Haas <rhaas@postgresql.org> | 2014-04-07 10:59:42 -0400 |
|---|---|---|
| committer | Robert Haas <rhaas@postgresql.org> | 2014-04-07 10:59:42 -0400 |
| commit | 315772e4ecf2e91f17a8e375afe8dff2c2174406 (patch) | |
| tree | c828c6a1ba21b18de535c6f37b3710fef60f7e01 | |
| parent | b8a721149b190dc09c00620f65cb85b190b83d45 (diff) | |
| download | postgresql-315772e4ecf2e91f17a8e375afe8dff2c2174406.tar.gz postgresql-315772e4ecf2e91f17a8e375afe8dff2c2174406.zip | |
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.
| -rw-r--r-- | src/backend/storage/lmgr/lock.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c index fd6cd0647ee..682506374fe 100644 --- 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); } |