diff options
Diffstat (limited to 'src/backend/utils/cache/relcache.c')
| -rw-r--r-- | src/backend/utils/cache/relcache.c | 122 |
1 files changed, 61 insertions, 61 deletions
diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c index c947bff4fca..5ff0d9e4fdf 100644 --- a/src/backend/utils/cache/relcache.c +++ b/src/backend/utils/cache/relcache.c @@ -124,7 +124,7 @@ bool criticalSharedRelcachesBuilt = false; /* * This counter counts relcache inval events received since backend startup - * (but only for rels that are actually in cache). Presently, we use it only + * (but only for rels that are actually in cache). Presently, we use it only * to detect whether data about to be written by write_relcache_init_file() * might already be obsolete. */ @@ -167,8 +167,8 @@ static bool eoxact_list_overflowed = false; * we don't need to access individual items except at EOXact. */ static TupleDesc *EOXactTupleDescArray; -static int NextEOXactTupleDescNum = 0; -static int EOXactTupleDescArrayLen = 0; +static int NextEOXactTupleDescNum = 0; +static int EOXactTupleDescArrayLen = 0; /* * macros to manipulate the lookup hashtables @@ -495,7 +495,7 @@ RelationBuildTupleDesc(Relation relation) Int16GetDatum(0)); /* - * Open pg_attribute and begin a scan. Force heap scan if we haven't yet + * Open pg_attribute and begin a scan. Force heap scan if we haven't yet * built the critical relcache entries (this includes initdb and startup * without a pg_internal.init file). */ @@ -558,7 +558,7 @@ RelationBuildTupleDesc(Relation relation) /* * The attcacheoff values we read from pg_attribute should all be -1 - * ("unknown"). Verify this if assert checking is on. They will be + * ("unknown"). Verify this if assert checking is on. They will be * computed when and if needed during tuple access. */ #ifdef USE_ASSERT_CHECKING @@ -572,7 +572,7 @@ RelationBuildTupleDesc(Relation relation) /* * However, we can easily set the attcacheoff value for the first - * attribute: it must be zero. This eliminates the need for special cases + * attribute: it must be zero. This eliminates the need for special cases * for attnum=1 that used to exist in fastgetattr() and index_getattr(). */ if (relation->rd_rel->relnatts > 0) @@ -628,7 +628,7 @@ RelationBuildTupleDesc(Relation relation) * each relcache entry that has associated rules. The context is used * just for rule info, not for any other subsidiary data of the relcache * entry, because that keeps the update logic in RelationClearRelation() - * manageable. The other subsidiary data structures are simple enough + * manageable. The other subsidiary data structures are simple enough * to be easy to free explicitly, anyway. */ static void @@ -736,9 +736,9 @@ RelationBuildRuleLock(Relation relation) /* * We want the rule's table references to be checked as though by the - * table owner, not the user referencing the rule. Therefore, scan + * table owner, not the user referencing the rule. Therefore, scan * through the rule's actions and set the checkAsUser field on all - * rtable entries. We have to look at the qual as well, in case it + * rtable entries. We have to look at the qual as well, in case it * contains sublinks. * * The reason for doing this when the rule is loaded, rather than when @@ -1014,25 +1014,24 @@ RelationInitPhysicalAddr(Relation relation) if (relation->rd_rel->relfilenode) { /* - * Even if we are using a decoding snapshot that doesn't represent - * the current state of the catalog we need to make sure the - * filenode points to the current file since the older file will - * be gone (or truncated). The new file will still contain older - * rows so lookups in them will work correctly. This wouldn't work - * correctly if rewrites were allowed to change the schema in a - * noncompatible way, but those are prevented both on catalog - * tables and on user tables declared as additional catalog - * tables. + * Even if we are using a decoding snapshot that doesn't represent the + * current state of the catalog we need to make sure the filenode + * points to the current file since the older file will be gone (or + * truncated). The new file will still contain older rows so lookups + * in them will work correctly. This wouldn't work correctly if + * rewrites were allowed to change the schema in a noncompatible way, + * but those are prevented both on catalog tables and on user tables + * declared as additional catalog tables. */ if (HistoricSnapshotActive() && RelationIsAccessibleInLogicalDecoding(relation) && IsTransactionState()) { - HeapTuple phys_tuple; - Form_pg_class physrel; + HeapTuple phys_tuple; + Form_pg_class physrel; phys_tuple = ScanPgRelation(RelationGetRelid(relation), - RelationGetRelid(relation) != ClassOidIndexId, + RelationGetRelid(relation) != ClassOidIndexId, true); if (!HeapTupleIsValid(phys_tuple)) elog(ERROR, "could not find pg_class entry for %u", @@ -1113,7 +1112,7 @@ RelationInitIndexAccessInfo(Relation relation) amsupport = aform->amsupport; /* - * Make the private context to hold index access info. The reason we need + * Make the private context to hold index access info. The reason we need * a context, and not just a couple of pallocs, is so that we won't leak * any subsidiary info attached to fmgr lookup records. * @@ -1161,7 +1160,7 @@ RelationInitIndexAccessInfo(Relation relation) /* * indcollation cannot be referenced directly through the C struct, - * because it comes after the variable-width indkey field. Must extract + * because it comes after the variable-width indkey field. Must extract * the datum the hard way... */ indcollDatum = fastgetattr(relation->rd_indextuple, @@ -1186,7 +1185,7 @@ RelationInitIndexAccessInfo(Relation relation) /* * Fill the support procedure OID array, as well as the info about - * opfamilies and opclass input types. (aminfo and supportinfo are left + * opfamilies and opclass input types. (aminfo and supportinfo are left * as zeroes, and are filled on-the-fly when used) */ IndexSupportInitialize(indclass, relation->rd_support, @@ -1274,7 +1273,7 @@ IndexSupportInitialize(oidvector *indclass, * Note there is no provision for flushing the cache. This is OK at the * moment because there is no way to ALTER any interesting properties of an * existing opclass --- all you can do is drop it, which will result in - * a useless but harmless dead entry in the cache. To support altering + * a useless but harmless dead entry in the cache. To support altering * opclass membership (not the same as opfamily membership!), we'd need to * be able to flush this cache as well as the contents of relcache entries * for indexes. @@ -1383,7 +1382,7 @@ LookupOpclassInfo(Oid operatorClassOid, heap_close(rel, AccessShareLock); /* - * Scan pg_amproc to obtain support procs for the opclass. We only fetch + * Scan pg_amproc to obtain support procs for the opclass. We only fetch * the default ones (those with lefttype = righttype = opcintype). */ if (numSupport > 0) @@ -1889,11 +1888,11 @@ RelationDestroyRelation(Relation relation, bool remember_tupdesc) { /* * If we Rebuilt a relcache entry during a transaction then its - * possible we did that because the TupDesc changed as the result - * of an ALTER TABLE that ran at less than AccessExclusiveLock. - * It's possible someone copied that TupDesc, in which case the - * copy would point to free'd memory. So if we rebuild an entry - * we keep the TupDesc around until end of transaction, to be safe. + * possible we did that because the TupDesc changed as the result of + * an ALTER TABLE that ran at less than AccessExclusiveLock. It's + * possible someone copied that TupDesc, in which case the copy would + * point to free'd memory. So if we rebuild an entry we keep the + * TupDesc around until end of transaction, to be safe. */ if (remember_tupdesc) RememberToFreeTupleDescAtEOX(relation->rd_att); @@ -1928,7 +1927,7 @@ RelationDestroyRelation(Relation relation, bool remember_tupdesc) * * NB: when rebuilding, we'd better hold some lock on the relation, * else the catalog data we need to read could be changing under us. - * Also, a rel to be rebuilt had better have refcnt > 0. This is because + * Also, a rel to be rebuilt had better have refcnt > 0. This is because * an sinval reset could happen while we're accessing the catalogs, and * the rel would get blown away underneath us by RelationCacheInvalidate * if it has zero refcnt. @@ -1951,7 +1950,7 @@ RelationClearRelation(Relation relation, bool rebuild) /* * Make sure smgr and lower levels close the relation's files, if they * weren't closed already. If the relation is not getting deleted, the - * next smgr access should reopen the files automatically. This ensures + * next smgr access should reopen the files automatically. This ensures * that the low-level file access state is updated after, say, a vacuum * truncation. */ @@ -2047,7 +2046,7 @@ RelationClearRelation(Relation relation, bool rebuild) * over from the old entry). This is to avoid trouble in case an * error causes us to lose control partway through. The old entry * will still be marked !rd_isvalid, so we'll try to rebuild it again - * on next access. Meanwhile it's not any less valid than it was + * on next access. Meanwhile it's not any less valid than it was * before, so any code that might expect to continue accessing it * isn't hurt by the rebuild failure. (Consider for example a * subtransaction that ALTERs a table and then gets canceled partway @@ -2237,7 +2236,7 @@ RelationCacheInvalidateEntry(Oid relationId) /* * RelationCacheInvalidate * Blow away cached relation descriptors that have zero reference counts, - * and rebuild those with positive reference counts. Also reset the smgr + * and rebuild those with positive reference counts. Also reset the smgr * relation cache and re-read relation mapping data. * * This is currently used only to recover from SI message buffer overflow, @@ -2250,7 +2249,7 @@ RelationCacheInvalidateEntry(Oid relationId) * We do this in two phases: the first pass deletes deletable items, and * the second one rebuilds the rebuildable items. This is essential for * safety, because hash_seq_search only copes with concurrent deletion of - * the element it is currently visiting. If a second SI overflow were to + * the element it is currently visiting. If a second SI overflow were to * occur while we are walking the table, resulting in recursive entry to * this routine, we could crash because the inner invocation blows away * the entry next to be visited by the outer scan. But this way is OK, @@ -2385,7 +2384,8 @@ RememberToFreeTupleDescAtEOX(TupleDesc td) { if (EOXactTupleDescArray == NULL) { - MemoryContext oldcxt; + MemoryContext oldcxt; + oldcxt = MemoryContextSwitchTo(CacheMemoryContext); EOXactTupleDescArray = (TupleDesc *) palloc(16 * sizeof(TupleDesc)); @@ -2395,12 +2395,12 @@ RememberToFreeTupleDescAtEOX(TupleDesc td) } else if (NextEOXactTupleDescNum >= EOXactTupleDescArrayLen) { - int32 newlen = EOXactTupleDescArrayLen * 2; + int32 newlen = EOXactTupleDescArrayLen * 2; Assert(EOXactTupleDescArrayLen > 0); EOXactTupleDescArray = (TupleDesc *) repalloc(EOXactTupleDescArray, - newlen * sizeof(TupleDesc)); + newlen * sizeof(TupleDesc)); EOXactTupleDescArrayLen = newlen; } @@ -2437,7 +2437,7 @@ AtEOXact_RelationCache(bool isCommit) * For simplicity, eoxact_list[] entries are not deleted till end of * top-level transaction, even though we could remove them at * subtransaction end in some cases, or remove relations from the list if - * they are cleared for other reasons. Therefore we should expect the + * they are cleared for other reasons. Therefore we should expect the * case that list entries are not found in the hashtable; if not, there's * nothing to do for them. */ @@ -2498,7 +2498,7 @@ AtEOXact_cleanup(Relation relation, bool isCommit) * transaction calls. (That seems bogus, but it's not worth fixing.) * * Note: ideally this check would be applied to every relcache entry, not - * just those that have eoxact work to do. But it's not worth forcing a + * just those that have eoxact work to do. But it's not worth forcing a * scan of the whole relcache just for this. (Moreover, doing so would * mean that assert-enabled testing never tests the hash_search code path * above, which seems a bad idea.) @@ -2809,7 +2809,7 @@ RelationBuildLocalRelation(const char *relname, /* * Insert relation physical and logical identifiers (OIDs) into the right - * places. For a mapped relation, we set relfilenode to zero and rely on + * places. For a mapped relation, we set relfilenode to zero and rely on * RelationInitPhysicalAddr to consult the map. */ rel->rd_rel->relisshared = shared_relation; @@ -3052,7 +3052,7 @@ RelationCacheInitializePhase2(void) oldcxt = MemoryContextSwitchTo(CacheMemoryContext); /* - * Try to load the shared relcache cache file. If unsuccessful, bootstrap + * Try to load the shared relcache cache file. If unsuccessful, bootstrap * the cache with pre-made descriptors for the critical shared catalogs. */ if (!load_relcache_init_file(true)) @@ -3132,9 +3132,9 @@ RelationCacheInitializePhase3(void) /* * If we didn't get the critical system indexes loaded into relcache, do - * so now. These are critical because the catcache and/or opclass cache + * 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 + * 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 * loaded into relcache. Thus, the flag criticalRelcachesBuilt is used to @@ -3151,7 +3151,7 @@ RelationCacheInitializePhase3(void) * RewriteRelRulenameIndexId and TriggerRelidNameIndexId are not critical * in the same way as the others, because the critical catalogs don't * (currently) have any rules or triggers, and so these indexes can be - * rebuilt without inducing recursion. However they are used during + * rebuilt without inducing recursion. However they are used during * relcache load when a rel does have rules or triggers, so we choose to * nail them for performance reasons. */ @@ -3182,7 +3182,7 @@ RelationCacheInitializePhase3(void) * * DatabaseNameIndexId isn't critical for relcache loading, but rather for * initial lookup of MyDatabaseId, without which we'll never find any - * non-shared catalogs at all. Autovacuum calls InitPostgres with a + * non-shared catalogs at all. Autovacuum calls InitPostgres with a * database OID, so it instead depends on DatabaseOidIndexId. We also * need to nail up some indexes on pg_authid and pg_auth_members for use * during client authentication. @@ -3617,7 +3617,7 @@ RelationGetIndexList(Relation relation) /* * We build the list we intend to return (in the caller's context) while - * doing the scan. After successfully completing the scan, we copy that + * doing the scan. After successfully completing the scan, we copy that * list into the relcache entry. This avoids cache-context memory leakage * if we get some sort of error partway through. */ @@ -3655,7 +3655,7 @@ RelationGetIndexList(Relation relation) /* * indclass cannot be referenced directly through the C struct, - * because it comes after the variable-width indkey field. Must + * because it comes after the variable-width indkey field. Must * extract the datum the hard way... */ indclassDatum = heap_getattr(htup, @@ -3970,16 +3970,16 @@ RelationGetIndexPredicate(Relation relation) Bitmapset * RelationGetIndexAttrBitmap(Relation relation, IndexAttrBitmapKind attrKind) { - Bitmapset *indexattrs; /* indexed columns */ - Bitmapset *uindexattrs; /* columns in unique indexes */ - Bitmapset *idindexattrs; /* columns in the replica identity */ + Bitmapset *indexattrs; /* indexed columns */ + Bitmapset *uindexattrs; /* columns in unique indexes */ + Bitmapset *idindexattrs; /* columns in the replica identity */ List *indexoidlist; ListCell *l; MemoryContext oldcxt; /* Quick exit if we already computed the result. */ if (relation->rd_indexattr != NULL) - switch(attrKind) + switch (attrKind) { case INDEX_ATTR_BITMAP_IDENTITY_KEY: return bms_copy(relation->rd_idattr); @@ -4023,8 +4023,8 @@ RelationGetIndexAttrBitmap(Relation relation, IndexAttrBitmapKind attrKind) Relation indexDesc; IndexInfo *indexInfo; int i; - bool isKey; /* candidate key */ - bool isIDKey; /* replica identity index */ + bool isKey; /* candidate key */ + bool isIDKey; /* replica identity index */ indexDesc = index_open(indexOid, AccessShareLock); @@ -4052,7 +4052,7 @@ RelationGetIndexAttrBitmap(Relation relation, IndexAttrBitmapKind attrKind) if (isIDKey) idindexattrs = bms_add_member(idindexattrs, - attrnum - FirstLowInvalidHeapAttributeNumber); + attrnum - FirstLowInvalidHeapAttributeNumber); if (isKey) uindexattrs = bms_add_member(uindexattrs, @@ -4079,7 +4079,7 @@ RelationGetIndexAttrBitmap(Relation relation, IndexAttrBitmapKind attrKind) MemoryContextSwitchTo(oldcxt); /* We return our original working copy for caller to play with */ - switch(attrKind) + switch (attrKind) { case INDEX_ATTR_BITMAP_IDENTITY_KEY: return idindexattrs; @@ -4268,7 +4268,7 @@ errtablecol(Relation rel, int attnum) * given directly rather than extracted from the relation's catalog data. * * Don't use this directly unless errtablecol() is inconvenient for some - * reason. This might possibly be needed during intermediate states in ALTER + * reason. This might possibly be needed during intermediate states in ALTER * TABLE, for instance. */ int @@ -4688,7 +4688,7 @@ load_relcache_init_file(bool shared) return true; /* - * init file is broken, so do it the hard way. We don't bother trying to + * init file is broken, so do it the hard way. We don't bother trying to * free the clutter we just allocated; it's not in the relcache so it * won't hurt. */ @@ -4753,7 +4753,7 @@ write_relcache_init_file(bool shared) } /* - * Write a magic number to serve as a file version identifier. We can + * Write a magic number to serve as a file version identifier. We can * change the magic number whenever the relcache layout changes. */ magic = RELCACHE_INIT_FILEMAGIC; @@ -4978,7 +4978,7 @@ RelationCacheInitFilePostInvalidate(void) * * We used to keep the init files across restarts, but that is unsafe in PITR * scenarios, and even in simple crash-recovery cases there are windows for - * the init files to become out-of-sync with the database. So now we just + * the init files to become out-of-sync with the database. So now we just * remove them during startup and expect the first backend launch to rebuild * them. Of course, this has to happen in each database of the cluster. */ |