diff options
Diffstat (limited to 'src/backend/utils/cache/relcache.c')
| -rw-r--r-- | src/backend/utils/cache/relcache.c | 64 |
1 files changed, 32 insertions, 32 deletions
diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c index f1140385883..8058169d067 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. */ @@ -472,7 +472,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). */ @@ -535,7 +535,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 @@ -549,7 +549,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) @@ -605,7 +605,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 @@ -714,9 +714,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 @@ -1059,7 +1059,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. * @@ -1107,7 +1107,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, @@ -1132,7 +1132,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, @@ -1220,7 +1220,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. @@ -1329,7 +1329,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) @@ -1855,7 +1855,7 @@ RelationDestroyRelation(Relation relation) * * 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. @@ -1878,7 +1878,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. */ @@ -1890,7 +1890,7 @@ RelationClearRelation(Relation relation, bool rebuild) * in case it is a mapped relation whose mapping changed. * * If it's a nailed index, then we need to re-read the pg_class row to see - * if its relfilenode changed. We can't necessarily do that here, because + * if its relfilenode changed. We can't necessarily do that here, because * we might be in a failed transaction. We assume it's okay to do it if * there are open references to the relcache entry (cf notes for * AtEOXact_RelationCache). Otherwise just mark the entry as possibly @@ -1951,7 +1951,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 @@ -2140,7 +2140,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, @@ -2153,7 +2153,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, @@ -2313,7 +2313,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. */ @@ -2363,7 +2363,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.) @@ -2667,7 +2667,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; @@ -2910,7 +2910,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)) @@ -2990,9 +2990,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 @@ -3009,7 +3009,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. */ @@ -3040,7 +3040,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. @@ -3472,7 +3472,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. */ @@ -3510,7 +3510,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, @@ -4060,7 +4060,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 @@ -4480,7 +4480,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. */ @@ -4545,7 +4545,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; @@ -4770,7 +4770,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. */ |