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

Commit 82b3684

Browse files
committed
Add comments spelling out why it's a good idea to release multiple
partition locks in reverse order.
1 parent e9e9750 commit 82b3684

File tree

2 files changed

+14
-6
lines changed

2 files changed

+14
-6
lines changed

src/backend/storage/lmgr/lock.c

+8-2
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $PostgreSQL: pgsql/src/backend/storage/lmgr/lock.c,v 1.176 2007/02/01 19:10:28 momjian Exp $
11+
* $PostgreSQL: pgsql/src/backend/storage/lmgr/lock.c,v 1.177 2007/07/16 21:09:50 tgl Exp $
1212
*
1313
* NOTES
1414
* A lock table is a shared memory hash table. When
@@ -2119,7 +2119,13 @@ GetLockStatusData(void)
21192119
el++;
21202120
}
21212121

2122-
/* And release locks */
2122+
/*
2123+
* And release locks. We do this in reverse order for two reasons:
2124+
* (1) Anyone else who needs more than one of the locks will be trying
2125+
* to lock them in increasing order; we don't want to release the other
2126+
* process until it can get all the locks it needs.
2127+
* (2) This avoids O(N^2) behavior inside LWLockRelease.
2128+
*/
21232129
for (i = NUM_LOCK_PARTITIONS; --i >= 0;)
21242130
LWLockRelease(FirstLockMgrLock + i);
21252131

src/backend/storage/lmgr/proc.c

+6-4
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $PostgreSQL: pgsql/src/backend/storage/lmgr/proc.c,v 1.190 2007/06/19 22:01:15 tgl Exp $
11+
* $PostgreSQL: pgsql/src/backend/storage/lmgr/proc.c,v 1.191 2007/07/16 21:09:50 tgl Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -1168,9 +1168,11 @@ CheckDeadLock(void)
11681168
}
11691169

11701170
/*
1171-
* Release locks acquired at head of routine. Order is not critical, so
1172-
* do it back-to-front to avoid waking another CheckDeadLock instance
1173-
* before it can get all the locks.
1171+
* And release locks. We do this in reverse order for two reasons:
1172+
* (1) Anyone else who needs more than one of the locks will be trying
1173+
* to lock them in increasing order; we don't want to release the other
1174+
* process until it can get all the locks it needs.
1175+
* (2) This avoids O(N^2) behavior inside LWLockRelease.
11741176
*/
11751177
check_done:
11761178
for (i = NUM_LOCK_PARTITIONS; --i >= 0;)

0 commit comments

Comments
 (0)