From f2e68b7c2f5dd727815fbe24390996324d692d43 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat, 23 Jul 2022 15:10:01 -0500
Subject: [PATCH 09/10] fix whitespace

weird since c91560defc57f89f7e88632ea14ae77b5cec78ee

See also:
https://www.postgresql.org/message-id/CAFBsxsHtYvE1Txm+NYM5gB1C3EZN_qDPJOOsJK_VsC2DXqZfcA@mail.gmail.com
---
 src/backend/commands/indexcmds.c            |   2 +-
 src/backend/utils/activity/backend_status.c |   2 +-
 src/backend/utils/cache/inval.c             | 188 ++++++++++----------
 src/backend/utils/mmgr/mcxt.c               |   4 +-
 4 files changed, 98 insertions(+), 98 deletions(-)

diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index 16ec0b114e6..38e6d9ebe7e 100644
--- a/src/backend/commands/indexcmds.c
+++ b/src/backend/commands/indexcmds.c
@@ -2313,7 +2313,7 @@ GetDefaultOpClass(Oid type_id, Oid am_id)
  *	extended statistics, etc.
  *
  *	The parameters are typically: the original table name, the original field
- *	name, and a "type" string (such as "seq" or "pkey").    The field name
+ *	name, and a "type" string (such as "seq" or "pkey").  The field name
  *	and/or type can be NULL if not relevant.
  *
  *	The result is a palloc'd string.
diff --git a/src/backend/utils/activity/backend_status.c b/src/backend/utils/activity/backend_status.c
index 608d01ea0dd..f6e847ff3b6 100644
--- a/src/backend/utils/activity/backend_status.c
+++ b/src/backend/utils/activity/backend_status.c
@@ -786,7 +786,7 @@ pgstat_read_current_status(void)
 		 * Follow the protocol of retrying if st_changecount changes while we
 		 * copy the entry, or if it's odd.  (The check for odd is needed to
 		 * cover the case where we are able to completely copy the entry while
-		 * the source backend is between increment steps.)	We use a volatile
+		 * the source backend is between increment steps.)  We use a volatile
 		 * pointer here to ensure the compiler doesn't try to get cute.
 		 */
 		for (;;)
diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.c
index 0008826f67c..cc7de542b1e 100644
--- a/src/backend/utils/cache/inval.c
+++ b/src/backend/utils/cache/inval.c
@@ -3,100 +3,100 @@
  * inval.c
  *	  POSTGRES cache invalidation dispatcher code.
  *
- *	This is subtle stuff, so pay attention:
- *
- *	When a tuple is updated or deleted, our standard visibility rules
- *	consider that it is *still valid* so long as we are in the same command,
- *	ie, until the next CommandCounterIncrement() or transaction commit.
- *	(See access/heap/heapam_visibility.c, and note that system catalogs are
- *  generally scanned under the most current snapshot available, rather than
- *  the transaction snapshot.)	At the command boundary, the old tuple stops
- *	being valid and the new version, if any, becomes valid.  Therefore,
- *	we cannot simply flush a tuple from the system caches during heap_update()
- *	or heap_delete().  The tuple is still good at that point; what's more,
- *	even if we did flush it, it might be reloaded into the caches by a later
- *	request in the same command.  So the correct behavior is to keep a list
- *	of outdated (updated/deleted) tuples and then do the required cache
- *	flushes at the next command boundary.  We must also keep track of
- *	inserted tuples so that we can flush "negative" cache entries that match
- *	the new tuples; again, that mustn't happen until end of command.
- *
- *	Once we have finished the command, we still need to remember inserted
- *	tuples (including new versions of updated tuples), so that we can flush
- *	them from the caches if we abort the transaction.  Similarly, we'd better
- *	be able to flush "negative" cache entries that may have been loaded in
- *	place of deleted tuples, so we still need the deleted ones too.
- *
- *	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
- *	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
- *	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
- *	two events, delete + insert, for simplicity.  (If the update doesn't
- *	change the tuple hash value, catcache.c optimizes this into one event.)
- *
- *	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,
- *	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
- *	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
- *	catcaches may need invalidation for a given tuple.
- *
- *	Also, whenever we see an operation on a pg_class, pg_attribute, or
- *	pg_index tuple, we register a relcache flush operation for the relation
- *	described by that tuple (as specified in CacheInvalidateHeapTuple()).
- *	Likewise for pg_constraint tuples for foreign keys on relations.
- *
- *	We keep the relcache flush requests in lists separate from the catcache
- *	tuple flush requests.  This allows us to issue all the pending catcache
- *	flushes before we issue relcache flushes, which saves us from loading
- *	a catcache tuple during relcache load only to flush it again right away.
- *	Also, we avoid queuing multiple relcache flush requests for the same
- *	relation, since a relcache flush is relatively expensive to do.
- *	(XXX is it worth testing likewise for duplicate catcache flush entries?
- *	Probably not.)
- *
- *	Many subsystems own higher-level caches that depend on relcache and/or
- *	catcache, and they register callbacks here to invalidate their caches.
- *	While building a higher-level cache entry, a backend may receive a
- *	callback for the being-built entry or one of its dependencies.  This
- *	implies the new higher-level entry would be born stale, and it might
- *	remain stale for the life of the backend.  Many caches do not prevent
- *	that.  They rely on DDL for can't-miss catalog changes taking
- *	AccessExclusiveLock on suitable objects.  (For a change made with less
- *	locking, backends might never read the change.)  The relation cache,
- *	however, needs to reflect changes from CREATE INDEX CONCURRENTLY no later
- *	than the beginning of the next transaction.  Hence, when a relevant
- *	invalidation callback arrives during a build, relcache.c reattempts that
- *	build.  Caches with similar needs could do likewise.
- *
- *	If a relcache flush is issued for a system relation that we preload
- *	from the relcache init file, we must also delete the init file so that
- *	it will be rebuilt during the next backend restart.  The actual work of
- *	manipulating the init file is in relcache.c, but we keep track of the
- *	need for it here.
- *
- *	Currently, inval messages are sent without regard for the possibility
- *	that the object described by the catalog tuple might be a session-local
- *	object such as a temporary table.  This is because (1) this code has
- *	no practical way to tell the difference, and (2) it is not certain that
- *	other backends don't have catalog cache or even relcache entries for
- *	such tables, anyway; there is nothing that prevents that.  It might be
- *	worth trying to avoid sending such inval traffic in the future, if those
- *	problems can be overcome cheaply.
- *
- *	When wal_level=logical, write invalidations into WAL at each command end to
- *	support the decoding of the in-progress transactions.  See
- *	CommandEndInvalidationMessages.
+ * This is subtle stuff, so pay attention:
+ *
+ * When a tuple is updated or deleted, our standard visibility rules
+ * consider that it is *still valid* so long as we are in the same command,
+ * ie, until the next CommandCounterIncrement() or transaction commit.
+ * (See access/heap/heapam_visibility.c, and note that system catalogs are
+ * generally scanned under the most current snapshot available, rather than
+ * the transaction snapshot.)  At the command boundary, the old tuple stops
+ * being valid and the new version, if any, becomes valid.  Therefore,
+ * we cannot simply flush a tuple from the system caches during heap_update()
+ * or heap_delete().  The tuple is still good at that point; what's more,
+ * even if we did flush it, it might be reloaded into the caches by a later
+ * request in the same command.  So the correct behavior is to keep a list
+ * of outdated (updated/deleted) tuples and then do the required cache
+ * flushes at the next command boundary.  We must also keep track of
+ * inserted tuples so that we can flush "negative" cache entries that match
+ * the new tuples; again, that mustn't happen until end of command.
+ *
+ * Once we have finished the command, we still need to remember inserted
+ * tuples (including new versions of updated tuples), so that we can flush
+ * them from the caches if we abort the transaction.  Similarly, we'd better
+ * be able to flush "negative" cache entries that may have been loaded in
+ * place of deleted tuples, so we still need the deleted ones too.
+ *
+ * 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
+ * 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
+ * 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
+ * two events, delete + insert, for simplicity.  (If the update doesn't
+ * change the tuple hash value, catcache.c optimizes this into one event.)
+ *
+ * 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,
+ * 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
+ * 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
+ * catcaches may need invalidation for a given tuple.
+ *
+ * Also, whenever we see an operation on a pg_class, pg_attribute, or
+ * pg_index tuple, we register a relcache flush operation for the relation
+ * described by that tuple (as specified in CacheInvalidateHeapTuple()).
+ * Likewise for pg_constraint tuples for foreign keys on relations.
+ *
+ * We keep the relcache flush requests in lists separate from the catcache
+ * tuple flush requests.  This allows us to issue all the pending catcache
+ * flushes before we issue relcache flushes, which saves us from loading
+ * a catcache tuple during relcache load only to flush it again right away.
+ * Also, we avoid queuing multiple relcache flush requests for the same
+ * relation, since a relcache flush is relatively expensive to do.
+ * (XXX is it worth testing likewise for duplicate catcache flush entries?
+ * Probably not.)
+ *
+ * Many subsystems own higher-level caches that depend on relcache and/or
+ * catcache, and they register callbacks here to invalidate their caches.
+ * While building a higher-level cache entry, a backend may receive a
+ * callback for the being-built entry or one of its dependencies.  This
+ * implies the new higher-level entry would be born stale, and it might
+ * remain stale for the life of the backend.  Many caches do not prevent
+ * that.  They rely on DDL for can't-miss catalog changes taking
+ * AccessExclusiveLock on suitable objects.  (For a change made with less
+ * locking, backends might never read the change.)  The relation cache,
+ * however, needs to reflect changes from CREATE INDEX CONCURRENTLY no later
+ * than the beginning of the next transaction.  Hence, when a relevant
+ * invalidation callback arrives during a build, relcache.c reattempts that
+ * build.  Caches with similar needs could do likewise.
+ *
+ * If a relcache flush is issued for a system relation that we preload
+ * from the relcache init file, we must also delete the init file so that
+ * it will be rebuilt during the next backend restart.  The actual work of
+ * manipulating the init file is in relcache.c, but we keep track of the
+ * need for it here.
+ *
+ * Currently, inval messages are sent without regard for the possibility
+ * that the object described by the catalog tuple might be a session-local
+ * object such as a temporary table.  This is because (1) this code has
+ * no practical way to tell the difference, and (2) it is not certain that
+ * other backends don't have catalog cache or even relcache entries for
+ * such tables, anyway; there is nothing that prevents that.  It might be
+ * worth trying to avoid sending such inval traffic in the future, if those
+ * problems can be overcome cheaply.
+ *
+ * When wal_level=logical, write invalidations into WAL at each command end to
+ * support the decoding of the in-progress transactions.  See
+ * CommandEndInvalidationMessages.
  *
  * Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
diff --git a/src/backend/utils/mmgr/mcxt.c b/src/backend/utils/mmgr/mcxt.c
index 4646ae50277..bdaa9539e40 100644
--- a/src/backend/utils/mmgr/mcxt.c
+++ b/src/backend/utils/mmgr/mcxt.c
@@ -928,7 +928,7 @@ MemoryContextCheck(MemoryContext context)
  * context creation routines, not by the unwashed masses.
  *
  * The memory context creation procedure goes like this:
- *	1.  Context-type-specific routine makes some initial space allocation,
+ *	1.	Context-type-specific routine makes some initial space allocation,
  *		including enough space for the context header.  If it fails,
  *		it can ereport() with no damage done.
  *	2.	Context-type-specific routine sets up all type-specific fields of
@@ -938,7 +938,7 @@ MemoryContextCheck(MemoryContext context)
  *		the initial space allocation should be freed before ereport'ing.
  *	3.	Context-type-specific routine calls MemoryContextCreate() to fill in
  *		the generic header fields and link the context into the context tree.
- *	4.  We return to the context-type-specific routine, which finishes
+ *	4.	We return to the context-type-specific routine, which finishes
  *		up type-specific initialization.  This routine can now do things
  *		that might fail (like allocate more memory), so long as it's
  *		sure the node is left in a state that delete will handle.
-- 
2.25.1

