mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add comments spelling out why it's a good idea to release multiple

Browse Source 
partition locks in reverse order.
This commit is contained in:
Tom Lane 2007-07-16 21:09:50 +00:00
parent e9e97500c9
commit 82b3684672
2 changed files with 14 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/storage/lmgr/lock.c
View File

@ -8,7 +8,7 @@
* *
* *
* IDENTIFICATION * IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/storage/lmgr/lock.c,v 1.176 2007/02/01 19:10:28 momjian Exp $ * $PostgreSQL: pgsql/src/backend/storage/lmgr/lock.c,v 1.177 2007/07/16 21:09:50 tgl Exp $
* *
* NOTES * NOTES
* A lock table is a shared memory hash table. When * A lock table is a shared memory hash table. When
@ -2119,7 +2119,13 @@ GetLockStatusData(void)
el++; el++;
} }
/* And release locks */ /*
* And release locks. We do this in reverse order for two reasons:
* (1) Anyone else who needs more than one of the locks will be trying
* to lock them in increasing order; we don't want to release the other
* process until it can get all the locks it needs.
* (2) This avoids O(N^2) behavior inside LWLockRelease.
*/
for (i = NUM_LOCK_PARTITIONS; --i >= 0;) for (i = NUM_LOCK_PARTITIONS; --i >= 0;)
LWLockRelease(FirstLockMgrLock + i); LWLockRelease(FirstLockMgrLock + i);

10
src/backend/storage/lmgr/proc.c
View File

@ -8,7 +8,7 @@
* *
* *
* IDENTIFICATION * IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/storage/lmgr/proc.c,v 1.190 2007/06/19 22:01:15 tgl Exp $ * $PostgreSQL: pgsql/src/backend/storage/lmgr/proc.c,v 1.191 2007/07/16 21:09:50 tgl Exp $
* *
*------------------------------------------------------------------------- *-------------------------------------------------------------------------
*/ */
@ -1168,9 +1168,11 @@ CheckDeadLock(void)
} }
/* /*
* Release locks acquired at head of routine. Order is not critical, so * And release locks. We do this in reverse order for two reasons:
* do it back-to-front to avoid waking another CheckDeadLock instance * (1) Anyone else who needs more than one of the locks will be trying
* before it can get all the locks. * to lock them in increasing order; we don't want to release the other
* process until it can get all the locks it needs.
* (2) This avoids O(N^2) behavior inside LWLockRelease.
*/ */
check_done: check_done:
for (i = NUM_LOCK_PARTITIONS; --i >= 0;) for (i = NUM_LOCK_PARTITIONS; --i >= 0;)