Remove uses of "slave" in replication contexts

This affects mostly code comments, some documentation, and tests.
Official APIs already used "standby".

src/backend/access/transam/commit_ts.c

@@ -621,7 +621,7 @@ CommitTsParameterChange(bool newvalue, bool oldvalue)
  *
  * The reason why this SLRU needs separate activation/deactivation functions is
  * that it can be enabled/disabled during start and the activation/deactivation
- * on master is propagated to slave via replay. Other SLRUs don't have this
+ * on master is propagated to standby via replay. Other SLRUs don't have this
  * property and they can be just initialized during normal startup.
  *
  * This is in charge of creating the currently active segment, if it's not

src/backend/access/transam/multixact.c

@@ -939,7 +939,7 @@ GetNewMultiXactId(int nmembers, MultiXactOffset *offset)
 
 	debug_elog3(DEBUG2, "GetNew: for %d xids", nmembers);
 
-	/* safety check, we should never get this far in a HS slave */
+	/* safety check, we should never get this far in a HS standby */
 	if (RecoveryInProgress())
 		elog(ERROR, "cannot assign MultiXactIds during recovery");
 

src/backend/access/transam/varsup.c

@@ -67,7 +67,7 @@ GetNewTransactionId(bool isSubXact)
 		return BootstrapTransactionId;
 	}
 
-	/* safety check, we should never get this far in a HS slave */
+	/* safety check, we should never get this far in a HS standby */
 	if (RecoveryInProgress())
 		elog(ERROR, "cannot assign TransactionIds during recovery");
 
@@ -468,7 +468,7 @@ GetNewObjectId(void)
 {
 	Oid			result;
 
-	/* safety check, we should never get this far in a HS slave */
+	/* safety check, we should never get this far in a HS standby */
 	if (RecoveryInProgress())
 		elog(ERROR, "cannot assign OIDs during recovery");
 

src/backend/catalog/namespace.c

@@ -3802,10 +3802,10 @@ InitTempTableNamespace(void)
 						get_database_name(MyDatabaseId))));
 
 	/*
-	 * Do not allow a Hot Standby slave session to make temp tables.  Aside
+	 * Do not allow a Hot Standby session to make temp tables.  Aside
 	 * from problems with modifying the system catalogs, there is a naming
 	 * conflict: pg_temp_N belongs to the session with BackendId N on the
-	 * master, not to a slave session with the same BackendId.  We should not
+	 * master, not to a hot standby session with the same BackendId.  We should not
 	 * be able to get here anyway due to XactReadOnly checks, but let's just
 	 * make real sure.  Note that this also backstops various operations that
 	 * allow XactReadOnly transactions to modify temp tables; they'd need

src/backend/commands/variable.c

@@ -472,8 +472,8 @@ show_log_timezone(void)
  * We allow idempotent changes (r/w -> r/w and r/o -> r/o) at any time, and
  * we also always allow changes from read-write to read-only.  However,
  * read-only may be changed to read-write only when in a top-level transaction
- * that has not yet taken an initial snapshot.  Can't do it in a hot standby
- * slave, either.
+ * that has not yet taken an initial snapshot.  Can't do it in a hot standby,
+ * either.
  *
  * If we are not in a transaction at all, just allow the change; it means
  * nothing since XactReadOnly will be reset by the next StartTransaction().

src/backend/executor/execMain.c

@@ -759,8 +759,8 @@ ExecCheckRTEPermsModified(Oid relOid, Oid userid, Bitmapset *modifiedCols,
  * unless we're in parallel mode, in which case don't even allow writes
  * to temp tables.
  *
- * Note: in a Hot Standby slave this would need to reject writes to temp
- * tables just as we do in parallel mode; but an HS slave can't have created
+ * Note: in a Hot Standby this would need to reject writes to temp
+ * tables just as we do in parallel mode; but an HS standby can't have created
  * any temp tables in the first place, so no need to check that.
  */
 static void

src/backend/replication/walsender.c

@@ -2572,7 +2572,7 @@ XLogSendPhysical(void)
 		 * fsync'd to disk.  We cannot go further than what's been written out
 		 * given the current implementation of XLogRead().  And in any case
 		 * it's unsafe to send WAL that is not securely down to disk on the
-		 * master: if the master subsequently crashes and restarts, slaves
+		 * master: if the master subsequently crashes and restarts, standbys
 		 * must not have applied any WAL that got lost on the master.
 		 */
 		SendRqstPtr = GetFlushRecPtr();

src/backend/storage/ipc/procarray.c

@@ -1408,7 +1408,7 @@ GetOldestXmin(Relation rel, int flags)
 		 * being careful not to generate a "permanent" XID.
 		 *
 		 * vacuum_defer_cleanup_age provides some additional "slop" for the
-		 * benefit of hot standby queries on slave servers.  This is quick and
+		 * benefit of hot standby queries on standby servers.  This is quick and
 		 * dirty, and perhaps not all that useful unless the master has a
 		 * predictable transaction rate, but it offers some protection when
 		 * there's no walsender connection.  Note that we are assuming

src/backend/tcop/utility.c

@@ -264,7 +264,7 @@ PreventCommandIfParallelMode(const char *cmdname)
 /*
  * PreventCommandDuringRecovery: throw error if RecoveryInProgress
  *
- * The majority of operations that are unsafe in a Hot Standby slave
+ * The majority of operations that are unsafe in a Hot Standby
  * will be rejected by XactReadOnly tests.  However there are a few
  * commands that are allowed in "read-only" xacts but cannot be allowed
  * in Hot Standby mode.  Those commands should call this function.