mirror of
https://github.com/postgres/postgres.git
synced 2025-08-31 17:02:12 +03:00
Remove tabs after spaces in C comments
This was not changed in HEAD, but will be done later as part of a pgindent run. Future pgindent runs will also do this. Report by Tom Lane Backpatch through all supported branches, but not HEAD
This commit is contained in:
60
src/backend/utils/cache/relcache.c
vendored
60
src/backend/utils/cache/relcache.c
vendored
@@ -121,7 +121,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.
|
||||
*/
|
||||
@@ -447,7 +447,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).
|
||||
*/
|
||||
@@ -510,7 +510,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
|
||||
@@ -524,7 +524,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)
|
||||
@@ -580,7 +580,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
|
||||
@@ -689,9 +689,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
|
||||
@@ -1034,7 +1034,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.
|
||||
*
|
||||
@@ -1082,7 +1082,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,
|
||||
@@ -1107,7 +1107,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,
|
||||
@@ -1195,7 +1195,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.
|
||||
@@ -1304,7 +1304,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)
|
||||
@@ -1824,7 +1824,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.
|
||||
@@ -1847,7 +1847,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.
|
||||
*/
|
||||
@@ -1859,7 +1859,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
|
||||
@@ -1920,7 +1920,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
|
||||
@@ -2109,7 +2109,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,
|
||||
@@ -2122,7 +2122,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,
|
||||
@@ -2273,7 +2273,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. 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;
|
||||
@@ -2803,7 +2803,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))
|
||||
@@ -2883,9 +2883,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
|
||||
@@ -2902,7 +2902,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.
|
||||
*/
|
||||
@@ -2933,7 +2933,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.
|
||||
@@ -3365,7 +3365,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.
|
||||
*/
|
||||
@@ -3403,7 +3403,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,
|
||||
@@ -4279,7 +4279,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.
|
||||
*/
|
||||
@@ -4344,7 +4344,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;
|
||||
@@ -4569,7 +4569,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.
|
||||
*/
|
||||
|
Reference in New Issue
Block a user