Modify index-opening code to guarantee that the indexes of a relation

are opened in a consistent order by different backends (I ordered them
by index OID because that's easy, but any other consistent order would
do as well).  This avoids potential deadlock for index types that we
acquire exclusive locks on ... ie, rtree.

1 files changed, 15 insertions, 10 deletions

diff --git a/src/backend/executor/execUtils.c b/src/backend/executor/execUtils.c
index c1b6e5d79a3..3777b68e64c 100644
--- a/src/backend/executor/execUtils.c
+++ b/src/backend/executor/execUtils.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/executor/execUtils.c,v 1.60 2000/06/17 21:48:49 tgl Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/executor/execUtils.c,v 1.61 2000/06/19 23:40:47 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -799,15 +799,20 @@ ExecOpenIndices(RelationInfo *resultRelationInfo)
 		/* ----------------
 		 * Open (and lock, if necessary) the index relation
 		 *
-		 * Hack for not btree and hash indices: they use relation
-		 * level exclusive locking on update (i.e. - they are not
-		 * ready for MVCC) and so we have to exclusively lock
-		 * indices here to prevent deadlocks if we will scan them
-		 * - index_beginscan places AccessShareLock, indices
-		 * update methods don't use locks at all. We release this
-		 * lock in ExecCloseIndices. Note, that hashes use page
-		 * level locking - i.e. are not deadlock-free, - let's
-		 * them be on their way -:)) vadim 03-12-1998
+		 * Hack for not btree and hash indices: they use relation level
+		 * exclusive locking on update (i.e. - they are not ready for MVCC)
+		 * and so we have to exclusively lock indices here to prevent
+		 * deadlocks if we will scan them - index_beginscan places
+		 * AccessShareLock, indices update methods don't use locks at all.
+		 * We release this lock in ExecCloseIndices. Note, that hashes use
+		 * page level locking - i.e. are not deadlock-free - let's them be
+		 * on their way -:)) vadim 03-12-1998
+		 *
+		 * If there are multiple not-btree-or-hash indices, all backends must
+		 * lock the indices in the same order or we will get deadlocks here
+		 * during concurrent updates.  This is now guaranteed by
+		 * RelationGetIndexList(), which promises to return the index list
+		 * in OID order.  tgl 06-19-2000
 		 * ----------------
 		 */
 		indexDesc = index_open(indexOid);