database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-29 10:41:53 +03:00
Code Activity

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

Browse Source 
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.
This commit is contained in:
Tom Lane
2000-06-19 23:40:48 +00:00
parent 1f75cdd5ed
commit a1dfaef6c6
2 changed files with 71 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
src/backend/executor/execUtils.c
View File

@ -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);