diff options
Diffstat (limited to 'src/backend/utils/cache')
| -rw-r--r-- | src/backend/utils/cache/attoptcache.c | 2 | ||||
| -rw-r--r-- | src/backend/utils/cache/catcache.c | 16 | ||||
| -rw-r--r-- | src/backend/utils/cache/inval.c | 30 | ||||
| -rw-r--r-- | src/backend/utils/cache/lsyscache.c | 10 | ||||
| -rw-r--r-- | src/backend/utils/cache/plancache.c | 20 | ||||
| -rw-r--r-- | src/backend/utils/cache/relcache.c | 58 | ||||
| -rw-r--r-- | src/backend/utils/cache/relmapper.c | 22 | ||||
| -rw-r--r-- | src/backend/utils/cache/spccache.c | 6 | ||||
| -rw-r--r-- | src/backend/utils/cache/syscache.c | 4 | ||||
| -rw-r--r-- | src/backend/utils/cache/typcache.c | 8 |
10 files changed, 88 insertions, 88 deletions
diff --git a/src/backend/utils/cache/attoptcache.c b/src/backend/utils/cache/attoptcache.c index 7018ccfe62a..b6f00478e9c 100644 --- a/src/backend/utils/cache/attoptcache.c +++ b/src/backend/utils/cache/attoptcache.c @@ -48,7 +48,7 @@ typedef struct * Flush all cache entries when pg_attribute is updated. * * When pg_attribute is updated, we must flush the cache entry at least - * for that attribute. Currently, we just flush them all. Since attribute + * for that attribute. Currently, we just flush them all. Since attribute * options are not currently used in performance-critical paths (such as * query execution), this seems OK. */ diff --git a/src/backend/utils/cache/catcache.c b/src/backend/utils/cache/catcache.c index 00f17d9edc6..81dcf3361f8 100644 --- a/src/backend/utils/cache/catcache.c +++ b/src/backend/utils/cache/catcache.c @@ -823,7 +823,7 @@ InitCatCache(int id, * CatalogCacheInitializeCache * * This function does final initialization of a catcache: obtain the tuple - * descriptor and set up the hash and equality function links. We assume + * descriptor and set up the hash and equality function links. We assume * that the relcache entry can be opened at this point! */ #ifdef CACHEDEBUG @@ -1048,7 +1048,7 @@ IndexScanOK(CatCache *cache, ScanKey cur_skey) * if necessary (on the first access to a particular cache). * * The result is NULL if not found, or a pointer to a HeapTuple in - * the cache. The caller must not modify the tuple, and must call + * the cache. The caller must not modify the tuple, and must call * ReleaseCatCache() when done with it. * * The search key values should be expressed as Datums of the key columns' @@ -1175,8 +1175,8 @@ SearchCatCache(CatCache *cache, * the relation --- for example, due to shared-cache-inval messages being * processed during heap_open(). This is OK. It's even possible for one * of those lookups to find and enter the very same tuple we are trying to - * fetch here. If that happens, we will enter a second copy of the tuple - * into the cache. The first copy will never be referenced again, and + * fetch here. If that happens, we will enter a second copy of the tuple + * into the cache. The first copy will never be referenced again, and * will eventually age out of the cache, so there's no functional problem. * This case is rare enough that it's not worth expending extra cycles to * detect. @@ -1215,7 +1215,7 @@ SearchCatCache(CatCache *cache, * * In bootstrap mode, we don't build negative entries, because the cache * invalidation mechanism isn't alive and can't clear them if the tuple - * gets created later. (Bootstrap doesn't do UPDATEs, so it doesn't need + * gets created later. (Bootstrap doesn't do UPDATEs, so it doesn't need * cache inval for that.) */ if (ct == NULL) @@ -1502,7 +1502,7 @@ SearchCatCacheList(CatCache *cache, /* * We are now past the last thing that could trigger an elog before we * have finished building the CatCList and remembering it in the - * resource owner. So it's OK to fall out of the PG_TRY, and indeed + * resource owner. So it's OK to fall out of the PG_TRY, and indeed * we'd better do so before we start marking the members as belonging * to the list. */ @@ -1592,7 +1592,7 @@ ReleaseCatCacheList(CatCList *list) /* * CatalogCacheCreateEntry * Create a new CatCTup entry, copying the given HeapTuple and other - * supplied data into it. The new entry initially has refcount 0. + * supplied data into it. The new entry initially has refcount 0. */ static CatCTup * CatalogCacheCreateEntry(CatCache *cache, HeapTuple ntp, @@ -1727,7 +1727,7 @@ build_dummy_tuple(CatCache *cache, int nkeys, ScanKey skeys) * the specified relation, find all catcaches it could be in, compute the * correct hash value for each such catcache, and call the specified function * to record the cache id, hash value, and tuple ItemPointer in inval.c's - * lists. CatalogCacheIdInvalidate will be called later, if appropriate, + * lists. CatalogCacheIdInvalidate will be called later, if appropriate, * using the recorded information. * * Note that it is irrelevant whether the given tuple is actually loaded diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.c index 4249bd33765..396cc0bea69 100644 --- a/src/backend/utils/cache/inval.c +++ b/src/backend/utils/cache/inval.c @@ -29,23 +29,23 @@ * * If we successfully complete the transaction, we have to broadcast all * these invalidation events to other backends (via the SI message queue) - * so that they can flush obsolete entries from their caches. Note we have + * so that they can flush obsolete entries from their caches. Note we have * to record the transaction commit before sending SI messages, otherwise * the other backends won't see our updated tuples as good. * * When a subtransaction aborts, we can process and discard any events - * it has queued. When a subtransaction commits, we just add its events + * it has queued. When a subtransaction commits, we just add its events * to the pending lists of the parent transaction. * * In short, we need to remember until xact end every insert or delete - * of a tuple that might be in the system caches. Updates are treated as + * of a tuple that might be in the system caches. Updates are treated as * two events, delete + insert, for simplicity. (There are cases where * it'd be possible to record just one event, but we don't currently try.) * * We do not need to register EVERY tuple operation in this way, just those - * on tuples in relations that have associated catcaches. We do, however, + * on tuples in relations that have associated catcaches. We do, however, * have to register every operation on every tuple that *could* be in a - * catcache, whether or not it currently is in our cache. Also, if the + * catcache, whether or not it currently is in our cache. Also, if the * tuple is in a relation that has multiple catcaches, we need to register * an invalidation message for each such catcache. catcache.c's * PrepareToInvalidateCacheTuple() routine provides the knowledge of which @@ -103,7 +103,7 @@ /* * To minimize palloc traffic, we keep pending requests in successively- * larger chunks (a slightly more sophisticated version of an expansible - * array). All request types can be stored as SharedInvalidationMessage + * array). All request types can be stored as SharedInvalidationMessage * records. The ordering of requests within a list is never significant. */ typedef struct InvalidationChunk @@ -630,7 +630,7 @@ PrepareForTupleInvalidation(Relation relation, HeapTuple tuple) * This essentially means that only backends in this same database * will react to the relcache flush request. This is in fact * appropriate, since only those backends could see our pg_attribute - * change anyway. It looks a bit ugly though. (In practice, shared + * change anyway. It looks a bit ugly though. (In practice, shared * relations can't have schema changes after bootstrap, so we should * never come here for a shared rel anyway.) */ @@ -642,7 +642,7 @@ PrepareForTupleInvalidation(Relation relation, HeapTuple tuple) /* * When a pg_index row is updated, we should send out a relcache inval - * for the index relation. As above, we don't know the shared status + * for the index relation. As above, we don't know the shared status * of the index, but in practice it doesn't matter since indexes of * shared catalogs can't have such updates. */ @@ -688,7 +688,7 @@ AcceptInvalidationMessages(void) * * If you're a glutton for punishment, try CLOBBER_CACHE_RECURSIVELY. This * slows things by at least a factor of 10000, so I wouldn't suggest - * trying to run the entire regression tests that way. It's useful to try + * trying to run the entire regression tests that way. It's useful to try * a few simple tests, to make sure that cache reload isn't subject to * internal cache-flush hazards, but after you've done a few thousand * recursive reloads it's unlikely you'll learn more. @@ -901,12 +901,12 @@ ProcessCommittedInvalidationMessages(SharedInvalidationMessage *msgs, * If isCommit, we must send out the messages in our PriorCmdInvalidMsgs list * to the shared invalidation message queue. Note that these will be read * not only by other backends, but also by our own backend at the next - * transaction start (via AcceptInvalidationMessages). This means that + * transaction start (via AcceptInvalidationMessages). This means that * we can skip immediate local processing of anything that's still in * CurrentCmdInvalidMsgs, and just send that list out too. * * If not isCommit, we are aborting, and must locally process the messages - * in PriorCmdInvalidMsgs. No messages need be sent to other backends, + * in PriorCmdInvalidMsgs. No messages need be sent to other backends, * since they'll not have seen our changed tuples anyway. We can forget * about CurrentCmdInvalidMsgs too, since those changes haven't touched * the caches yet. @@ -965,11 +965,11 @@ AtEOXact_Inval(bool isCommit) * parent's PriorCmdInvalidMsgs list. * * If not isCommit, we are aborting, and must locally process the messages - * in PriorCmdInvalidMsgs. No messages need be sent to other backends. + * in PriorCmdInvalidMsgs. No messages need be sent to other backends. * We can forget about CurrentCmdInvalidMsgs too, since those changes haven't * touched the caches yet. * - * In any case, pop the transaction stack. We need not physically free memory + * In any case, pop the transaction stack. We need not physically free memory * here, since CurTransactionContext is about to be emptied anyway * (if aborting). Beware of the possibility of aborting the same nesting * level twice, though. @@ -1025,7 +1025,7 @@ AtEOSubXact_Inval(bool isCommit) * in a transaction. * * Here, we send no messages to the shared queue, since we don't know yet if - * we will commit. We do need to locally process the CurrentCmdInvalidMsgs + * we will commit. We do need to locally process the CurrentCmdInvalidMsgs * list, so as to flush our caches of any entries we have outdated in the * current command. We then move the current-cmd list over to become part * of the prior-cmds list. @@ -1155,7 +1155,7 @@ CacheInvalidateRelcacheByRelid(Oid relid) * * Sending this type of invalidation msg forces other backends to close open * smgr entries for the rel. This should be done to flush dangling open-file - * references when the physical rel is being dropped or truncated. Because + * references when the physical rel is being dropped or truncated. Because * these are nontransactional (i.e., not-rollback-able) operations, we just * send the inval message immediately without any queuing. * diff --git a/src/backend/utils/cache/lsyscache.c b/src/backend/utils/cache/lsyscache.c index 6435541bb63..c90909c95cd 100644 --- a/src/backend/utils/cache/lsyscache.c +++ b/src/backend/utils/cache/lsyscache.c @@ -182,13 +182,13 @@ get_opfamily_member(Oid opfamily, Oid lefttype, Oid righttype, * (This indicates that the operator is not a valid ordering operator.) * * Note: the operator could be registered in multiple families, for example - * if someone were to build a "reverse sort" opfamily. This would result in + * if someone were to build a "reverse sort" opfamily. This would result in * uncertainty as to whether "ORDER BY USING op" would default to NULLS FIRST * or NULLS LAST, as well as inefficient planning due to failure to match up * pathkeys that should be the same. So we want a determinate result here. * Because of the way the syscache search works, we'll use the interpretation * associated with the opfamily with smallest OID, which is probably - * determinate enough. Since there is no longer any particularly good reason + * determinate enough. Since there is no longer any particularly good reason * to build reverse-sort opfamilies, it doesn't seem worth expending any * additional effort on ensuring consistency. */ @@ -386,7 +386,7 @@ get_ordering_op_for_equality_op(Oid opno, bool use_lhs_type) * * The planner currently uses simple equal() tests to compare the lists * returned by this function, which makes the list order relevant, though - * strictly speaking it should not be. Because of the way syscache list + * strictly speaking it should not be. Because of the way syscache list * searches are handled, in normal operation the result will be sorted by OID * so everything works fine. If running with system index usage disabled, * the result ordering is unspecified and hence the planner might fail to @@ -1195,7 +1195,7 @@ op_mergejoinable(Oid opno, Oid inputtype) * * In some cases (currently only array_eq), hashjoinability depends on the * specific input data type the operator is invoked for, so that must be - * passed as well. We currently assume that only one input's type is needed + * passed as well. We currently assume that only one input's type is needed * to check this --- by convention, pass the left input's data type. */ bool @@ -1825,7 +1825,7 @@ get_typbyval(Oid typid) * A two-fer: given the type OID, return both typlen and typbyval. * * Since both pieces of info are needed to know how to copy a Datum, - * many places need both. Might as well get them with one cache lookup + * many places need both. Might as well get them with one cache lookup * instead of two. Also, this routine raises an error instead of * returning a bogus value when given a bad type OID. */ diff --git a/src/backend/utils/cache/plancache.c b/src/backend/utils/cache/plancache.c index 5dcea3db33a..8894ff8076f 100644 --- a/src/backend/utils/cache/plancache.c +++ b/src/backend/utils/cache/plancache.c @@ -12,16 +12,16 @@ * * The plan cache manager itself is principally responsible for tracking * whether cached plans should be invalidated because of schema changes in - * the objects they depend on. When (and if) the next demand for a cached + * the objects they depend on. When (and if) the next demand for a cached * plan occurs, the query will be replanned. Note that this could result * in an error, for example if a column referenced by the query is no - * longer present. The creator of a cached plan can specify whether it + * longer present. The creator of a cached plan can specify whether it * is allowable for the query to change output tupdesc on replan (this * could happen with "SELECT *" for example) --- if so, it's up to the * caller to notice changes and cope with them. * * Currently, we track exactly the dependencies of plans on relations and - * user-defined functions. On relcache invalidation events or pg_proc + * user-defined functions. On relcache invalidation events or pg_proc * syscache invalidation events, we invalidate just those plans that depend * on the particular object being modified. (Note: this scheme assumes * that any table modification that requires replanning will generate a @@ -209,7 +209,7 @@ CreateCachedPlan(Node *raw_parse_tree, * avoids extra copy steps during plan construction. If the query ever does * need replanning, we'll generate a separate new CachedPlan at that time, but * the CachedPlanSource and the initial CachedPlan share the caller-provided - * context and go away together when neither is needed any longer. (Because + * context and go away together when neither is needed any longer. (Because * the parser and planner generate extra cruft in addition to their real * output, this approach means that the context probably contains a bunch of * useless junk as well as the useful trees. Hence, this method is a @@ -300,7 +300,7 @@ FastCreateCachedPlan(Node *raw_parse_tree, * CachedPlanSetParserHook: set up to use parser callback hooks * * Use this when a caller wants to manage parameter information via parser - * callbacks rather than a fixed parameter-types list. Beware that the + * callbacks rather than a fixed parameter-types list. Beware that the * information pointed to by parserSetupArg must be valid for as long as * the cached plan might be replanned! */ @@ -377,7 +377,7 @@ StoreCachedPlan(CachedPlanSource *plansource, { /* * Planner already extracted dependencies, we don't have to ... except - * in the case of EXPLAIN. We assume here that EXPLAIN can't appear + * in the case of EXPLAIN. We assume here that EXPLAIN can't appear * in a list with other commands. */ plan->relationOids = plan->invalItems = NIL; @@ -410,7 +410,7 @@ StoreCachedPlan(CachedPlanSource *plansource, * DropCachedPlan: destroy a cached plan. * * Actually this only destroys the CachedPlanSource: the referenced CachedPlan - * is released, but not destroyed until its refcount goes to zero. That + * is released, but not destroyed until its refcount goes to zero. That * handles the situation where DropCachedPlan is called while the plan is * still in use. */ @@ -586,7 +586,7 @@ RevalidateCachedPlan(CachedPlanSource *plansource, bool useResOwner) } /* - * Check or update the result tupdesc. XXX should we use a weaker + * Check or update the result tupdesc. XXX should we use a weaker * condition than equalTupleDescs() here? */ resultDesc = PlanCacheComputeResultDesc(slist); @@ -651,7 +651,7 @@ RevalidateCachedPlan(CachedPlanSource *plansource, bool useResOwner) * * Note: useResOwner = false is used for releasing references that are in * persistent data structures, such as the parent CachedPlanSource or a - * Portal. Transient references should be protected by a resource owner. + * Portal. Transient references should be protected by a resource owner. */ void ReleaseCachedPlan(CachedPlan *plan, bool useResOwner) @@ -925,7 +925,7 @@ plan_list_is_transient(List *stmt_list) /* * PlanCacheComputeResultDesc: given a list of either fully-planned statements - * or Queries, determine the result tupledesc it will produce. Returns NULL + * or Queries, determine the result tupledesc it will produce. Returns NULL * if the execution will not return tuples. * * Note: the result is created or copied into current memory context. 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. */ diff --git a/src/backend/utils/cache/relmapper.c b/src/backend/utils/cache/relmapper.c index a19ee28b53b..6d2a0198588 100644 --- a/src/backend/utils/cache/relmapper.c +++ b/src/backend/utils/cache/relmapper.c @@ -23,7 +23,7 @@ * mapped catalogs can only be relocated by operations such as VACUUM FULL * and CLUSTER, which make no transactionally-significant changes: it must be * safe for the new file to replace the old, even if the transaction itself - * aborts. An important factor here is that the indexes and toast table of + * aborts. An important factor here is that the indexes and toast table of * a mapped catalog must also be mapped, so that the rewrites/relocations of * all these files commit in a single map file update rather than being tied * to transaction commit. @@ -58,13 +58,13 @@ /* * The map file is critical data: we have no automatic method for recovering * from loss or corruption of it. We use a CRC so that we can detect - * corruption. To minimize the risk of failed updates, the map file should + * corruption. To minimize the risk of failed updates, the map file should * be kept to no more than one standard-size disk sector (ie 512 bytes), * and we use overwrite-in-place rather than playing renaming games. * The struct layout below is designed to occupy exactly 512 bytes, which * might make filesystem updates a bit more efficient. * - * Entries in the mappings[] array are in no particular order. We could + * Entries in the mappings[] array are in no particular order. We could * speed searching by insisting on OID order, but it really shouldn't be * worth the trouble given the intended size of the mapping sets. */ @@ -91,7 +91,7 @@ typedef struct RelMapFile /* * The currently known contents of the shared map file and our database's - * local map file are stored here. These can be reloaded from disk + * local map file are stored here. These can be reloaded from disk * immediately whenever we receive an update sinval message. */ static RelMapFile shared_map; @@ -294,7 +294,7 @@ merge_map_updates(RelMapFile *map, const RelMapFile *updates, bool add_okay) * RelationMapRemoveMapping * * Remove a relation's entry in the map. This is only allowed for "active" - * (but not committed) local mappings. We need it so we can back out the + * (but not committed) local mappings. We need it so we can back out the * entry for the transient target file when doing VACUUM FULL/CLUSTER on * a mapped relation. */ @@ -322,7 +322,7 @@ RelationMapRemoveMapping(Oid relationId) * RelationMapInvalidate * * This routine is invoked for SI cache flush messages. We must re-read - * the indicated map file. However, we might receive a SI message in a + * the indicated map file. However, we might receive a SI message in a * process that hasn't yet, and might never, load the mapping files; * for example the autovacuum launcher, which *must not* try to read * a local map since it is attached to no particular database. @@ -390,7 +390,7 @@ AtCCI_RelationMap(void) * * During commit, this must be called as late as possible before the actual * transaction commit, so as to minimize the window where the transaction - * could still roll back after committing map changes. Although nothing + * could still roll back after committing map changes. Although nothing * critically bad happens in such a case, we still would prefer that it * not happen, since we'd possibly be losing useful updates to the relations' * pg_class row(s). @@ -457,7 +457,7 @@ AtPrepare_RelationMap(void) /* * CheckPointRelationMap * - * This is called during a checkpoint. It must ensure that any relation map + * This is called during a checkpoint. It must ensure that any relation map * updates that were WAL-logged before the start of the checkpoint are * securely flushed to disk and will not need to be replayed later. This * seems unlikely to be a performance-critical issue, so we use a simple @@ -647,7 +647,7 @@ load_relmap_file(bool shared) * * Because this may be called during WAL replay when MyDatabaseId, * DatabasePath, etc aren't valid, we require the caller to pass in suitable - * values. The caller is also responsible for being sure no concurrent + * values. The caller is also responsible for being sure no concurrent * map update could be happening. */ static void @@ -675,7 +675,7 @@ write_relmap_file(bool shared, RelMapFile *newmap, * critical section, so that an open() failure need not force PANIC. * * Note: since we use BasicOpenFile, we are nominally responsible for - * ensuring the fd is closed on error. In practice, this isn't important + * ensuring the fd is closed on error. In practice, this isn't important * because either an error happens inside the critical section, or we are * in bootstrap or WAL replay; so an error past this point is always fatal * anyway. @@ -773,7 +773,7 @@ write_relmap_file(bool shared, RelMapFile *newmap, /* * Make sure that the files listed in the map are not deleted if the outer - * transaction aborts. This had better be within the critical section + * transaction aborts. This had better be within the critical section * too: it's not likely to fail, but if it did, we'd arrive at transaction * abort with the files still vulnerable. PANICing will leave things in a * good state on-disk. diff --git a/src/backend/utils/cache/spccache.c b/src/backend/utils/cache/spccache.c index 57e5d0342a6..a306c481db6 100644 --- a/src/backend/utils/cache/spccache.c +++ b/src/backend/utils/cache/spccache.c @@ -4,7 +4,7 @@ * Tablespace cache management. * * We cache the parsed version of spcoptions for each tablespace to avoid - * needing to reparse on every lookup. Right now, there doesn't appear to + * needing to reparse on every lookup. Right now, there doesn't appear to * be a measurable performance gain from doing this, but that might change * in the future as we add more options. * @@ -128,7 +128,7 @@ get_tablespace(Oid spcid) return spc; /* - * Not found in TableSpace cache. Check catcache. If we don't find a + * Not found in TableSpace cache. Check catcache. If we don't find a * valid HeapTuple, it must mean someone has managed to request tablespace * details for a non-existent tablespace. We'll just treat that case as * if no options were specified. @@ -158,7 +158,7 @@ get_tablespace(Oid spcid) } /* - * Now create the cache entry. It's important to do this only after + * Now create the cache entry. It's important to do this only after * reading the pg_tablespace entry, since doing so could cause a cache * flush. */ diff --git a/src/backend/utils/cache/syscache.c b/src/backend/utils/cache/syscache.c index 99e5f1d9fe6..55d852e95e4 100644 --- a/src/backend/utils/cache/syscache.c +++ b/src/backend/utils/cache/syscache.c @@ -764,7 +764,7 @@ static bool CacheInitialized = false; * InitCatalogCache - initialize the caches * * Note that no database access is done here; we only allocate memory - * and initialize the cache structure. Interrogation of the database + * and initialize the cache structure. Interrogation of the database * to complete initialization of a cache happens upon first use * of that cache. */ @@ -1001,7 +1001,7 @@ SearchSysCacheExistsAttName(Oid relid, const char *attname) * extract a specific attribute. * * This is equivalent to using heap_getattr() on a tuple fetched - * from a non-cached relation. Usually, this is only used for attributes + * from a non-cached relation. Usually, this is only used for attributes * that could be NULL or variable length; the fixed-size attributes in * a system table are accessed just by mapping the tuple onto the C struct * declarations from include/catalog/. diff --git a/src/backend/utils/cache/typcache.c b/src/backend/utils/cache/typcache.c index 5fd02958cf1..06972e4da9d 100644 --- a/src/backend/utils/cache/typcache.c +++ b/src/backend/utils/cache/typcache.c @@ -11,7 +11,7 @@ * * Several seemingly-odd choices have been made to support use of the type * cache by generic array and record handling routines, such as array_eq(), - * record_cmp(), and hash_array(). Because those routines are used as index + * record_cmp(), and hash_array(). Because those routines are used as index * support operations, they cannot leak memory. To allow them to execute * efficiently, all information that they would like to re-use across calls * is kept in the type cache. @@ -99,7 +99,7 @@ typedef struct TypeCacheEnumData * * Stored record types are remembered in a linear array of TupleDescs, * which can be indexed quickly with the assigned typmod. There is also - * a hash table to speed searches for matching TupleDescs. The hash key + * a hash table to speed searches for matching TupleDescs. The hash key * uses just the first N columns' type OIDs, and so we may have multiple * entries with the same hash key. */ @@ -468,7 +468,7 @@ load_typcache_tupdesc(TypeCacheEntry *typentry) /* * Link to the tupdesc and increment its refcount (we assert it's a - * refcounted descriptor). We don't use IncrTupleDescRefCount() for this, + * refcounted descriptor). We don't use IncrTupleDescRefCount() for this, * because the reference mustn't be entered in the current resource owner; * it can outlive the current query. */ @@ -1004,7 +1004,7 @@ load_enum_cache_data(TypeCacheEntry *tcache) /* * Read all the information for members of the enum type. We collect the * info in working memory in the caller's context, and then transfer it to - * permanent memory in CacheMemoryContext. This minimizes the risk of + * permanent memory in CacheMemoryContext. This minimizes the risk of * leaking memory from CacheMemoryContext in the event of an error partway * through. */ |