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

partition locks in reverse order.

diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index fa062a1f7b77a4c85a334a2a498abd4515100da5..a4a0910d393026cc27156be489dc4e8c719a1aa6 100644 (file)
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -8,7 +8,7 @@
  *
  *
  * 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
  *   A lock table is a shared memory hash table.  When
@@ -2119,7 +2119,13 @@ GetLockStatusData(void)
        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;)
        LWLockRelease(FirstLockMgrLock + i);
 

diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c
index 367c0e6cf813bfea20cf5ea2ac0eefc9ef6e3b77..6e7efe6d6c9b47e821afea45fa9728d1755be777 100644 (file)
--- a/src/backend/storage/lmgr/proc.c
+++ b/src/backend/storage/lmgr/proc.c
@@ -8,7 +8,7 @@
  *
  *
  * 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
-    * do it back-to-front to avoid waking another CheckDeadLock instance
-    * before it can get all the 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.
     */
 check_done:
    for (i = NUM_LOCK_PARTITIONS; --i >= 0;)