diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2006-12-31 20:32:04 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2006-12-31 20:32:04 +0000 |
| commit | 0b56be83441c01419fcf82ebe666e968e6f7b246 (patch) | |
| tree | 77aafcc3cb26fcdc5284844227cedf88c6f7957a /src | |
| parent | 5725b9d9afc8c3ba24e94cbc7020889fe8ad7ef9 (diff) | |
| download | postgresql-0b56be83441c01419fcf82ebe666e968e6f7b246.tar.gz postgresql-0b56be83441c01419fcf82ebe666e968e6f7b246.zip | |
Found the problem with my operator-family changes: by fetching from
pg_opclass during LookupOpclassInfo(), I'd turned pg_opclass_oid_index
into a critical system index. However the problem could only manifest
during a backend's first attempt to load opclass data, and then only
if it had successfully loaded pg_internal.init and subsequently received
a relcache flush; which made it impossible to reproduce in sequential
tests and darn hard even in parallel tests. Memo to self: when
exercising cache flush scenarios, must disable LookupOpclassInfo's
internal cache too.
Diffstat (limited to 'src')
| -rw-r--r-- | src/backend/utils/cache/relcache.c | 9 |
1 files changed, 5 insertions, 4 deletions
diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c index be5fb60dc8e..327bba7b682 100644 --- a/src/backend/utils/cache/relcache.c +++ b/src/backend/utils/cache/relcache.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/utils/cache/relcache.c,v 1.251 2006/12/23 00:43:11 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/utils/cache/relcache.c,v 1.252 2006/12/31 20:32:04 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -2402,8 +2402,8 @@ RelationCacheInitializePhase2(void) /* * If we didn't get the critical system indexes loaded into relcache, do - * so now. These are critical because the catcache depends on them for - * catcache fetches that are done during relcache load. Thus, we have an + * so now. These are critical because the catcache and/or opclass cache + * depend on them for fetches done during relcache load. Thus, we have an * infinite-recursion problem. We can break the recursion by doing * heapscans instead of indexscans at certain key spots. To avoid hobbling * performance, we only want to do that until we have the critical indexes @@ -2439,13 +2439,14 @@ RelationCacheInitializePhase2(void) LOAD_CRIT_INDEX(ClassOidIndexId); LOAD_CRIT_INDEX(AttributeRelidNumIndexId); LOAD_CRIT_INDEX(IndexRelidIndexId); + LOAD_CRIT_INDEX(OpclassOidIndexId); LOAD_CRIT_INDEX(AccessMethodStrategyIndexId); LOAD_CRIT_INDEX(AccessMethodProcedureIndexId); LOAD_CRIT_INDEX(OperatorOidIndexId); LOAD_CRIT_INDEX(RewriteRelRulenameIndexId); LOAD_CRIT_INDEX(TriggerRelidNameIndexId); -#define NUM_CRITICAL_INDEXES 8 /* fix if you change list above */ +#define NUM_CRITICAL_INDEXES 9 /* fix if you change list above */ criticalRelcachesBuilt = true; } |