Consistently use "startup process"/"WAL sender" instead of "Startup process"/"WAL Sender" in comments and docs.

From cc3c1541940358b804e4d806cd7912f3b9807f9c Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: Sun, 13 Feb 2022 08:10:04 +0000
Subject: [PATCH v1] s/Startup process/startup process/ and s/WAL Sender/WAL
 sender

Consistently use "startup process"/"WAL sender" instead of
"Startup process"/"WAL Sender" in comments and docs.
---
 doc/src/sgml/high-availability.sgml        |  8 +++----
 src/backend/access/transam/README          |  4 ++--
 src/backend/access/transam/xlog.c          |  2 +-
 src/backend/postmaster/postmaster.c        |  6 ++---
 src/backend/postmaster/startup.c           |  4 ++--
 src/backend/replication/walreceiverfuncs.c |  2 +-
 src/backend/storage/buffer/bufmgr.c        |  4 ++--
 src/backend/storage/ipc/sinvaladt.c        |  2 +-
 src/backend/storage/ipc/standby.c          | 28 +++++++++++-----------
 src/backend/storage/lmgr/README            | 16 ++++++-------
 src/backend/storage/lmgr/proc.c            |  6 ++---
 src/backend/tcop/postgres.c                |  2 +-
 src/include/replication/walreceiver.h      |  2 +-
 src/include/storage/proc.h                 |  4 ++--
 14 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 437712762a..888ab6c226 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -2127,7 +2127,7 @@ HINT:  You can then restart the server after making the necessary configuration
    <para>
     <function>pg_cancel_backend()</function>
     and <function>pg_terminate_backend()</function> will work on user backends,
-    but not the Startup process, which performs
+    but not the startup process, which performs
     recovery. <structname>pg_stat_activity</structname> does not show
     recovering transactions as active. As a result,
     <structname>pg_prepared_xacts</structname> is always empty during
@@ -2139,11 +2139,11 @@ HINT:  You can then restart the server after making the necessary configuration
    <para>
     <structname>pg_locks</structname> will show locks held by backends,
     as normal. <structname>pg_locks</structname> also shows
-    a virtual transaction managed by the Startup process that owns all
+    a virtual transaction managed by the startup process that owns all
     <literal>AccessExclusiveLocks</literal> held by transactions being replayed by recovery.
-    Note that the Startup process does not acquire locks to
+    Note that the startup process does not acquire locks to
     make database changes, and thus locks other than <literal>AccessExclusiveLocks</literal>
-    do not show in <structname>pg_locks</structname> for the Startup
+    do not show in <structname>pg_locks</structname> for the startup
     process; they are just presumed to exist.
    </para>
 
diff --git a/src/backend/access/transam/README b/src/backend/access/transam/README
index 1edc8180c1..09fdd920fd 100644
--- a/src/backend/access/transam/README
+++ b/src/backend/access/transam/README
@@ -618,8 +618,8 @@ or more buffer locks be held concurrently, you must lock the pages in
 appropriate order, and not release the locks until all the changes are done.
 
 Note that we must only use PageSetLSN/PageGetLSN() when we know the action
-is serialised. Only Startup process may modify data blocks during recovery,
-so Startup process may execute PageGetLSN() without fear of serialisation
+is serialized. Only startup process may modify data blocks during recovery,
+so startup process may execute PageGetLSN() without fear of serialisation
 problems. All other processes must only call PageSet/GetLSN when holding
 either an exclusive buffer lock or a shared lock plus buffer header lock,
 or be writing the data block directly rather than through shared buffers
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 958220c495..7fa252c894 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -9321,7 +9321,7 @@ CreateCheckPoint(int flags)
 	 * allows us to reconstruct the state of running transactions during
 	 * archive recovery, if required. Skip, if this info disabled.
 	 *
-	 * If we are shutting down, or Startup process is completing crash
+	 * If we are shutting down, or startup process is completing crash
 	 * recovery we don't need to write running xact data.
 	 */
 	if (!shutdown && XLogStandbyInfoActive())
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index ce90877154..355bb3f5df 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -4182,7 +4182,7 @@ SignalSomeChildren(int signal, int target)
 		if (target != BACKEND_TYPE_ALL)
 		{
 			/*
-			 * Assign bkend_type for any recently announced WAL Sender
+			 * Assign bkend_type for any recently announced WAL sender
 			 * processes.
 			 */
 			if (bp->bkend_type == BACKEND_TYPE_NORMAL &&
@@ -5370,7 +5370,7 @@ sigusr1_handler(SIGNAL_ARGS)
 		/*
 		 * Tell startup process to finish recovery.
 		 *
-		 * Leave the promote signal file in place and let the Startup process
+		 * Leave the promote signal file in place and let the startup process
 		 * do the unlink.
 		 */
 		signal_child(StartupPID, SIGUSR2);
@@ -5460,7 +5460,7 @@ CountChildren(int target)
 		if (target != BACKEND_TYPE_ALL)
 		{
 			/*
-			 * Assign bkend_type for any recently announced WAL Sender
+			 * Assign bkend_type for any recently announced WAL sender
 			 * processes.
 			 */
 			if (bp->bkend_type == BACKEND_TYPE_NORMAL &&
diff --git a/src/backend/postmaster/startup.c b/src/backend/postmaster/startup.c
index 9bae16bfc7..389b8874ea 100644
--- a/src/backend/postmaster/startup.c
+++ b/src/backend/postmaster/startup.c
@@ -2,9 +2,9 @@
  *
  * startup.c
  *
- * The Startup process initialises the server and performs any recovery
+ * The startup process initialises the server and performs any recovery
  * actions that have been specified. Notice that there is no "main loop"
- * since the Startup process ends as soon as initialisation is complete.
+ * since the startup process ends as soon as initialisation is complete.
  * (in standby mode, one can think of the replay loop as a main loop,
  * though.)
  *
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index c50728ea22..90414b5479 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -172,7 +172,7 @@ WalRcvStreaming(void)
 
 /*
  * Stop walreceiver (if running) and wait for it to die.
- * Executed by the Startup process.
+ * Executed by the startup process.
  */
 void
 ShutdownWalRcv(void)
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index f5459c68f8..133f7ac0fe 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -4168,7 +4168,7 @@ LockBufferForCleanup(Buffer buffer)
 			if (log_recovery_conflict_waits && waitStart == 0)
 				waitStart = GetCurrentTimestamp();
 
-			/* Publish the bufid that Startup process waits on */
+			/* Publish the bufid that startup process waits on */
 			SetStartupBufferPinWaitBufId(buffer - 1);
 			/* Set alarm and then wait to be signaled by UnpinBuffer() */
 			ResolveRecoveryConflictWithBufferPin();
@@ -4207,7 +4207,7 @@ HoldingBufferPinThatDelaysRecovery(void)
 	int			bufid = GetStartupBufferPinWaitBufId();
 
 	/*
-	 * If we get woken slowly then it's possible that the Startup process was
+	 * If we get woken slowly then it's possible that the startup process was
 	 * already woken by other backends before we got here. Also possible that
 	 * we get here by multiple interrupts or interrupts at inappropriate
 	 * times, so make sure we do nothing if the bufid is not set.
diff --git a/src/backend/storage/ipc/sinvaladt.c b/src/backend/storage/ipc/sinvaladt.c
index 68e7160b30..63d2095ee8 100644
--- a/src/backend/storage/ipc/sinvaladt.c
+++ b/src/backend/storage/ipc/sinvaladt.c
@@ -148,7 +148,7 @@ typedef struct ProcState
 
 	/*
 	 * Backend only sends invalidations, never receives them. This only makes
-	 * sense for Startup process during recovery because it doesn't maintain a
+	 * sense for startup process during recovery because it doesn't maintain a
 	 * relcache, yet it fires inval messages to allow query backends to see
 	 * schema changes.
 	 */
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index 87ac0f74b2..50bce96479 100644
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -75,7 +75,7 @@ typedef struct RecoveryLockListsEntry
  * lock table entries for each transaction but its simpler just to create
  * one permanent entry and leave it there all the time. Locks are then
  * acquired and released as needed. Yes, this means you can see the
- * Startup process in pg_locks once we have run this.
+ * startup process in pg_locks once we have run this.
  */
 void
 InitRecoveryTransactionEnvironment(void)
@@ -95,7 +95,7 @@ InitRecoveryTransactionEnvironment(void)
 									HASH_ELEM | HASH_BLOBS);
 
 	/*
-	 * Initialize shared invalidation management for Startup process, being
+	 * Initialize shared invalidation management for startup process, being
 	 * careful to register ourselves as a sendOnly process so we don't need to
 	 * read messages, nor will we get signaled when the queue starts filling
 	 * up.
@@ -103,7 +103,7 @@ InitRecoveryTransactionEnvironment(void)
 	SharedInvalBackendInit(true);
 
 	/*
-	 * Lock a virtual transaction id for Startup process.
+	 * Lock a virtual transaction id for startup process.
 	 *
 	 * We need to do GetNextLocalTransactionId() because
 	 * SharedInvalBackendInit() leaves localTransactionId invalid and the lock
@@ -565,7 +565,7 @@ ResolveRecoveryConflictWithDatabase(Oid dbid)
  * lock.  As we are already queued to be granted the lock, no new lock
  * requests conflicting with ours will be granted in the meantime.
  *
- * We also must check for deadlocks involving the Startup process and
+ * We also must check for deadlocks involving the startup process and
  * hot-standby backend processes. If deadlock_timeout is reached in
  * this function, all the backends holding the conflicting locks are
  * requested to check themselves for deadlocks.
@@ -713,7 +713,7 @@ cleanup:
 
 	/*
 	 * Clear any timeout requests established above.  We assume here that the
-	 * Startup process doesn't have any other outstanding timeouts than those
+	 * startup process doesn't have any other outstanding timeouts than those
 	 * used by this function. If that stops being true, we could cancel the
 	 * timeouts individually, but that'd be slower.
 	 */
@@ -733,13 +733,13 @@ cleanup:
  * the limit of our patience.
  *
  * Resolve conflicts by sending a PROCSIG signal to all backends to check if
- * they hold one of the buffer pins that is blocking Startup process. If so,
+ * they hold one of the buffer pins that is blocking startup process. If so,
  * those backends will take an appropriate error action, ERROR or FATAL.
  *
  * We also must check for deadlocks.  Deadlocks occur because if queries
  * wait on a lock, that must be behind an AccessExclusiveLock, which can only
- * be cleared if the Startup process replays a transaction completion record.
- * If Startup process is also waiting then that is a deadlock. The deadlock
+ * be cleared if the startup process replays a transaction completion record.
+ * If startup process is also waiting then that is a deadlock. The deadlock
  * can occur if the query is waiting and then the Startup sleeps, or if
  * Startup is sleeping and the query waits on a lock. We protect against
  * only the former sequence here, the latter sequence is checked prior to
@@ -822,7 +822,7 @@ ResolveRecoveryConflictWithBufferPin(void)
 
 	/*
 	 * Clear any timeout requests established above.  We assume here that the
-	 * Startup process doesn't have any other timeouts than what this function
+	 * startup process doesn't have any other timeouts than what this function
 	 * uses.  If that stops being true, we could cancel the timeouts
 	 * individually, but that'd be slower.
 	 */
@@ -838,7 +838,7 @@ SendRecoveryConflictWithBufferPin(ProcSignalReason reason)
 
 	/*
 	 * We send signal to all backends to ask them if they are holding the
-	 * buffer pin which is delaying the Startup process. We must not set the
+	 * buffer pin which is delaying the startup process. We must not set the
 	 * conflict flag yet, since most backends will be innocent. Let the
 	 * SIGUSR1 handling in each backend decide their own fate.
 	 */
@@ -852,7 +852,7 @@ SendRecoveryConflictWithBufferPin(ProcSignalReason reason)
  *
  * Note: this code is pessimistic, because there is no way for it to
  * determine whether an actual deadlock condition is present: the lock we
- * need to wait for might be unrelated to any held by the Startup process.
+ * need to wait for might be unrelated to any held by the startup process.
  * Sooner or later, this mechanism should get ripped out in favor of somehow
  * accounting for buffer locks in DeadLockCheck().  However, errors here
  * seem to be very low-probability in practice, so for now it's not worth
@@ -861,7 +861,7 @@ SendRecoveryConflictWithBufferPin(ProcSignalReason reason)
 void
 CheckRecoveryConflictDeadlock(void)
 {
-	Assert(!InRecovery);		/* do not call in Startup process */
+	Assert(!InRecovery);		/* do not call in startup process */
 
 	if (!HoldingBufferPinThatDelaysRecovery())
 		return;
@@ -923,7 +923,7 @@ StandbyLockTimeoutHandler(void)
  * Locking in Recovery Mode
  * -----------------------------------------------------
  *
- * All locks are held by the Startup process using a single virtual
+ * All locks are held by the startup process using a single virtual
  * transaction. This implementation is both simpler and in some senses,
  * more correct. The locks held mean "some original transaction held
  * this lock, so query access is not allowed at this time". So the Startup
@@ -934,7 +934,7 @@ StandbyLockTimeoutHandler(void)
  *
  * We keep a hash table of lists of locks in local memory keyed by xid,
  * RecoveryLockLists, so we can keep track of the various entries made by
- * the Startup process's virtual xid in the shared lock table.
+ * the startup process's virtual xid in the shared lock table.
  *
  * List elements use type xl_standby_lock, since the WAL record type exactly
  * matches the information that we need to keep track of.
diff --git a/src/backend/storage/lmgr/README b/src/backend/storage/lmgr/README
index d08ec6c402..49709cde81 100644
--- a/src/backend/storage/lmgr/README
+++ b/src/backend/storage/lmgr/README
@@ -711,29 +711,29 @@ are released at transaction end and do not need explicit unlocking.
 Locking during Hot Standby
 --------------------------
 
-The Startup process is the only backend that can make changes during
+The startup process is the only backend that can make changes during
 recovery, all other backends are read only.  As a result the Startup
 process does not acquire locks on relations or objects except when the lock
 level is AccessExclusiveLock.
 
 Regular backends are only allowed to take locks on relations or objects
 at RowExclusiveLock or lower. This ensures that they do not conflict with
-each other or with the Startup process, unless AccessExclusiveLocks are
-requested by the Startup process.
+each other or with the startup process, unless AccessExclusiveLocks are
+requested by the startup process.
 
 Deadlocks involving AccessExclusiveLocks are not possible, so we need
 not be concerned that a user initiated deadlock can prevent recovery from
 progressing.
 
 AccessExclusiveLocks on the primary node generate WAL records
-that are then applied by the Startup process. Locks are released at end
+that are then applied by the startup process. Locks are released at end
 of transaction just as they are in normal processing. These locks are
-held by the Startup process, acting as a proxy for the backends that
+held by the startup process, acting as a proxy for the backends that
 originally acquired these locks. Again, these locks cannot conflict with
-one another, so the Startup process cannot deadlock itself either.
+one another, so the startup process cannot deadlock itself either.
 
 Although deadlock is not possible, a regular backend's weak lock can
-prevent the Startup process from making progress in applying WAL, which is
+prevent the startup process from making progress in applying WAL, which is
 usually not something that should be tolerated for very long.  Mechanisms
 exist to forcibly cancel a regular backend's query if it blocks the
-Startup process for too long.
+startup process for too long.
diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c
index 37f032e7b9..1710eaadc5 100644
--- a/src/backend/storage/lmgr/proc.c
+++ b/src/backend/storage/lmgr/proc.c
@@ -510,7 +510,7 @@ InitProcessPhase2(void)
  * Startup process however uses locks but never waits for them in the
  * normal backend sense. Startup process also takes part in sinval messaging
  * as a sendOnly process, so never reads messages from sinval queue. So
- * Startup process does have a VXID and does show up in pg_locks.
+ * startup process does have a VXID and does show up in pg_locks.
  */
 void
 InitAuxiliaryProcess(void)
@@ -1216,8 +1216,8 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
 	/*
 	 * Also, now that we will successfully clean up after an ereport, it's
 	 * safe to check to see if there's a buffer pin deadlock against the
-	 * Startup process.  Of course, that's only necessary if we're doing Hot
-	 * Standby and are not the Startup process ourselves.
+	 * startup process.  Of course, that's only necessary if we're doing Hot
+	 * Standby and are not the startup process ourselves.
 	 */
 	if (RecoveryInProgress() && !InRecovery)
 		CheckRecoveryConflictDeadlock();
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index fda2e9360e..2c597ba217 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -3013,7 +3013,7 @@ RecoveryConflictInterrupt(ProcSignalReason reason)
 
 				/*
 				 * If PROCSIG_RECOVERY_CONFLICT_BUFFERPIN is requested but we
-				 * aren't blocking the Startup process there is nothing more
+				 * aren't blocking the startup process there is nothing more
 				 * to do.
 				 *
 				 * When PROCSIG_RECOVERY_CONFLICT_STARTUP_DEADLOCK is
diff --git a/src/include/replication/walreceiver.h b/src/include/replication/walreceiver.h
index 92f73a55b8..a2861e3db2 100644
--- a/src/include/replication/walreceiver.h
+++ b/src/include/replication/walreceiver.h
@@ -88,7 +88,7 @@ typedef struct
 	/*
 	 * latestChunkStart is the starting byte position of the current "batch"
 	 * of received WAL.  It's actually the same as the previous value of
-	 * flushedUpto before the last flush to disk.  Startup process can use
+	 * flushedUpto before the last flush to disk. Startup process can use
 	 * this to detect whether it's keeping up or not.
 	 */
 	XLogRecPtr	latestChunkStart;
diff --git a/src/include/storage/proc.h b/src/include/storage/proc.h
index a58888f9e9..95d43a49b5 100644
--- a/src/include/storage/proc.h
+++ b/src/include/storage/proc.h
@@ -359,7 +359,7 @@ typedef struct PROC_HDR
 	Latch	   *checkpointerLatch;
 	/* Current shared estimate of appropriate spins_per_delay value */
 	int			spins_per_delay;
-	/* Buffer id of the buffer that Startup process waits for pin on, or -1 */
+	/* Buffer id of the buffer that startup process waits for pin on, or -1 */
 	int			startupBufferPinWaitBufId;
 } PROC_HDR;
 
@@ -375,7 +375,7 @@ extern PGPROC *PreparedXactProcs;
  * ie things that aren't full-fledged backends but need shmem access.
  *
  * Background writer, checkpointer, WAL writer and archiver run during normal
- * operation.  Startup process and WAL receiver also consume 2 slots, but WAL
+ * operation. Startup process and WAL receiver also consume 2 slots, but WAL
  * writer is launched only after startup has exited, so we only need 5 slots.
  */
 #define NUM_AUXILIARY_PROCS		5
-- 
2.25.1