diff options
Diffstat (limited to 'src/backend/utils/cache/relcache.c')
| -rw-r--r-- | src/backend/utils/cache/relcache.c | 58 |
1 files changed, 29 insertions, 29 deletions
diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c index 29ae3878ef3..6d5ac6c8564 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. */ @@ -449,7 +449,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). */ @@ -512,7 +512,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 @@ -526,7 +526,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) @@ -582,7 +582,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 @@ -691,9 +691,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 @@ -1036,7 +1036,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. * @@ -1084,7 +1084,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, @@ -1109,7 +1109,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, @@ -1197,7 +1197,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. @@ -1306,7 +1306,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) @@ -1825,7 +1825,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. @@ -1848,7 +1848,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. */ @@ -1860,7 +1860,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 @@ -1921,7 +1921,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 @@ -2110,7 +2110,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, @@ -2123,7 +2123,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, @@ -2274,7 +2274,7 @@ AtEOXact_RelationCache(bool isCommit) * unless there is actually something for this routine to do. Other than * the debug-only Assert checks, most transactions don't create any work * for us to do here, so we keep a static flag that gets set if there is - * anything to do. (Currently, this means either a relation is created in + * anything to do. (Currently, this means either a relation is created in * the current xact, or one is given a new relfilenode, or an index list * is forced.) For simplicity, the flag remains set till end of top-level * transaction, even though we could clear it at subtransaction end in @@ -2570,7 +2570,7 @@ RelationBuildLocalRelation(const char *relname, /* * Insert relation physical and logical identifiers (OIDs) into the right - * places. Note that the physical ID (relfilenode) is initially the same + * places. Note that the physical ID (relfilenode) is initially the same * as the logical ID (OID); except that for a mapped relation, we set * relfilenode to zero and rely on RelationInitPhysicalAddr to consult the * map. @@ -2804,7 +2804,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)) @@ -2884,9 +2884,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 @@ -2903,7 +2903,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. */ @@ -2934,7 +2934,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. @@ -3360,7 +3360,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. */ @@ -4260,7 +4260,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. */ @@ -4325,7 +4325,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; @@ -4550,7 +4550,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. */ |