Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit3cb2f2a

Browse files
committed
Avoid potential deadlock in InitCatCachePhase2().
Opening a catcache's index could require reading from that cache's owncatalog, which of course would acquire AccessShareLock on the catalog.So the original coding here risks locking index before heap, which coulddeadlock against another backend trying to get exclusive locks in thenormal order. Because InitCatCachePhase2 is only called when a backendhas to start up without a relcache init file, the deadlock was seldom seenin the field. (And by the same token, there's no need to worry about anyperformance disadvantage; so not much point in trying to distinguishexactly which catalogs have the risk.)Bug report, diagnosis, and patch by Nikhil Sontakke. Additional commentaryby me. Back-patch to all supported branches.
1 parent38e5124 commit3cb2f2a

File tree

2 files changed

+19
-0
lines changed

2 files changed

+19
-0
lines changed

‎src/backend/utils/cache/catcache.c

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -26,6 +26,7 @@
2626
#ifdefCATCACHE_STATS
2727
#include"storage/ipc.h"/* for on_proc_exit */
2828
#endif
29+
#include"storage/lmgr.h"
2930
#include"utils/builtins.h"
3031
#include"utils/fmgroids.h"
3132
#include"utils/inval.h"
@@ -967,8 +968,16 @@ InitCatCachePhase2(CatCache *cache, bool touch_index)
967968
{
968969
Relationidesc;
969970

971+
/*
972+
* We must lock the underlying catalog before opening the index to
973+
* avoid deadlock, since index_open could possibly result in reading
974+
* this same catalog, and if anyone else is exclusive-locking this
975+
* catalog and index they'll be doing it in that order.
976+
*/
977+
LockRelationOid(cache->cc_reloid,AccessShareLock);
970978
idesc=index_open(cache->cc_indexoid,AccessShareLock);
971979
index_close(idesc,AccessShareLock);
980+
UnlockRelationOid(cache->cc_reloid,AccessShareLock);
972981
}
973982
}
974983

‎src/backend/utils/cache/relcache.c

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1690,6 +1690,12 @@ RelationClose(Relation relation)
16901690
*We assume that at the time we are called, we have at least AccessShareLock
16911691
*on the target index. (Note: in the calls from RelationClearRelation,
16921692
*this is legitimate because we know the rel has positive refcount.)
1693+
*
1694+
*If the target index is an index on pg_class or pg_index, we'd better have
1695+
*previously gotten at least AccessShareLock on its underlying catalog,
1696+
*else we are at risk of deadlock against someone trying to exclusive-lock
1697+
*the heap and index in that order. This is ensured in current usage by
1698+
*only applying this to indexes being opened or having positive refcount.
16931699
*/
16941700
staticvoid
16951701
RelationReloadIndexInfo(Relationrelation)
@@ -3636,6 +3642,10 @@ RelationGetIndexPredicate(Relation relation)
36363642
* Attribute numbers are offset by FirstLowInvalidHeapAttributeNumber so that
36373643
* we can include system attributes (e.g., OID) in the bitmap representation.
36383644
*
3645+
* Caller had better hold at least RowExclusiveLock on the target relation
3646+
* to ensure that it has a stable set of indexes. This also makes it safe
3647+
* (deadlock-free) for us to take locks on the relation's indexes.
3648+
*
36393649
* The returned result is palloc'd in the caller's memory context and should
36403650
* be bms_free'd when not needed anymore.
36413651
*/

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp