Remove uses of "slave" in replication contexts

petere · petere · commit a1ef920e27ba · 2017-08-10T22:55:41.000-04:00
This affects mostly code comments, some documentation, and tests.
Official APIs already used "standby".
diff --git a/contrib/dblink/expected/dblink.out b/contrib/dblink/expected/dblink.out
@@ -270,7 +270,7 @@ SELECT *
 FROM dblink('SELECT * FROM foo') AS t(a int, b text, c text[])
 WHERE t.a > 7;
 ERROR:  connection not available
--- put more data into our slave table, first using arbitrary connection syntax
+-- put more data into our table, first using arbitrary connection syntax
 -- but truncate the actual return value so we can use diff to check for success
 SELECT substr(dblink_exec(connection_parameters(),'INSERT INTO foo VALUES(10,''k'',''{"a10","b10","c10"}'')'),1,6);
  substr 
@@ -285,7 +285,7 @@ SELECT dblink_connect(connection_parameters());
  OK
 (1 row)
 
--- put more data into our slave table, using persistent connection syntax
+-- put more data into our table, using persistent connection syntax
 -- but truncate the actual return value so we can use diff to check for success
 SELECT substr(dblink_exec('INSERT INTO foo VALUES(11,''l'',''{"a11","b11","c11"}'')'),1,6);
  substr 
@@ -610,7 +610,7 @@ SELECT dblink_connect('myconn',connection_parameters());
  OK
 (1 row)
 
--- put more data into our slave table, using named persistent connection syntax
+-- put more data into our table, using named persistent connection syntax
 -- but truncate the actual return value so we can use diff to check for success
 SELECT substr(dblink_exec('myconn','INSERT INTO foo VALUES(11,''l'',''{"a11","b11","c11"}'')'),1,6);
  substr 
diff --git a/contrib/dblink/sql/dblink.sql b/contrib/dblink/sql/dblink.sql
@@ -160,14 +160,14 @@ SELECT *
 FROM dblink('SELECT * FROM foo') AS t(a int, b text, c text[])
 WHERE t.a > 7;
 
--- put more data into our slave table, first using arbitrary connection syntax
+-- put more data into our table, first using arbitrary connection syntax
 -- but truncate the actual return value so we can use diff to check for success
 SELECT substr(dblink_exec(connection_parameters(),'INSERT INTO foo VALUES(10,''k'',''{"a10","b10","c10"}'')'),1,6);
 
 -- create a persistent connection
 SELECT dblink_connect(connection_parameters());
 
--- put more data into our slave table, using persistent connection syntax
+-- put more data into our table, using persistent connection syntax
 -- but truncate the actual return value so we can use diff to check for success
 SELECT substr(dblink_exec('INSERT INTO foo VALUES(11,''l'',''{"a11","b11","c11"}'')'),1,6);
 
@@ -316,7 +316,7 @@ WHERE t.a > 7;
 -- create a named persistent connection
 SELECT dblink_connect('myconn',connection_parameters());
 
--- put more data into our slave table, using named persistent connection syntax
+-- put more data into our table, using named persistent connection syntax
 -- but truncate the actual return value so we can use diff to check for success
 SELECT substr(dblink_exec('myconn','INSERT INTO foo VALUES(11,''l'',''{"a11","b11","c11"}'')'),1,6);
 
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
@@ -40,7 +40,7 @@
   server to modify the data.  Servers that can modify data are
   called read/write, <firstterm>master</> or <firstterm>primary</> servers.
   Servers that track changes in the master are called <firstterm>standby</>
-  or <firstterm>slave</> servers. A standby server that cannot be connected
+  or <firstterm>secondary</> servers. A standby server that cannot be connected
   to until it is promoted to a master server is called a <firstterm>warm
   standby</> server, and one that can accept connections and serves read-only
   queries is called a <firstterm>hot standby</> server.
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
@@ -483,7 +483,7 @@ pg_upgrade.exe
 
       <para>
        From a directory that is above the old and new database cluster
-       directories, run this for each slave:
+       directories, run this for each standby:
 
 <programlisting>
 rsync --archive --delete --hard-links --size-only old_pgdata new_pgdata remote_dir
@@ -517,7 +517,7 @@ rsync --archive --delete --hard-links --size-only old_pgdata new_pgdata remote_d
       <para>
        Configure the servers for log shipping.  (You do not need to run
        <function>pg_start_backup()</> and <function>pg_stop_backup()</>
-       or take a file system backup as the slaves are still synchronized
+       or take a file system backup as the standbys are still synchronized
        with the master.)
       </para>
      </step>
diff --git a/src/backend/access/transam/commit_ts.c b/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
diff --git a/src/backend/access/transam/multixact.c b/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");
 
diff --git a/src/backend/access/transam/varsup.c b/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");
 
diff --git a/src/backend/catalog/namespace.c b/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
diff --git a/src/backend/commands/variable.c b/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().
diff --git a/src/backend/executor/execMain.c b/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
diff --git a/src/backend/replication/walsender.c b/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();
diff --git a/src/backend/storage/ipc/procarray.c b/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
diff --git a/src/backend/tcop/utility.c b/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.
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
@@ -676,7 +676,7 @@ main(int argc, char **argv)
 		dopt.no_security_labels = 1;
 
 	/*
-	 * On hot standby slaves, never try to dump unlogged table data, since it
+	 * On hot standbys, never try to dump unlogged table data, since it
 	 * will just throw an error.
 	 */
 	if (fout->isStandby)
diff --git a/src/bin/pg_rewind/RewindTest.pm b/src/bin/pg_rewind/RewindTest.pm
@@ -160,7 +160,7 @@ sub promote_standby
 	$node_master->poll_query_until('postgres', $wal_received_query)
 	  or die "Timed out while waiting for standby to receive and write WAL";
 
-	# Now promote slave and insert some new data on master, this will put
+	# Now promote standby and insert some new data on master, this will put
 	# the master out-of-sync with the standby.
 	$node_standby->promote;
 
diff --git a/src/test/modules/commit_ts/t/002_standby.pl b/src/test/modules/commit_ts/t/002_standby.pl
@@ -34,7 +34,7 @@
   $master->safe_psql('postgres', 'select pg_current_wal_lsn()');
 $standby->poll_query_until('postgres',
 	qq{SELECT '$master_lsn'::pg_lsn <= pg_last_wal_replay_lsn()})
-  or die "slave never caught up";
+  or die "standby never caught up";
 
 my $standby_ts = $standby->safe_psql('postgres',
 qq{select ts.* from pg_class, pg_xact_commit_timestamp(xmin) ts where relname = 't10'}
@@ -47,7 +47,7 @@
 $master_lsn = $master->safe_psql('postgres', 'select pg_current_wal_lsn()');
 $standby->poll_query_until('postgres',
 	qq{SELECT '$master_lsn'::pg_lsn <= pg_last_wal_replay_lsn()})
-  or die "slave never caught up";
+  or die "standby never caught up";
 $standby->safe_psql('postgres', 'checkpoint');
 
 # This one should raise an error now
diff --git a/src/test/modules/commit_ts/t/003_standby_2.pl b/src/test/modules/commit_ts/t/003_standby_2.pl
@@ -33,7 +33,7 @@
   $master->safe_psql('postgres', 'select pg_current_wal_lsn()');
 $standby->poll_query_until('postgres',
 	qq{SELECT '$master_lsn'::pg_lsn <= pg_last_wal_replay_lsn()})
-  or die "slave never caught up";
+  or die "standby never caught up";
 
 $standby->safe_psql('postgres', 'checkpoint');
 $standby->restart;
diff --git a/src/test/recovery/t/002_archiving.pl b/src/test/recovery/t/002_archiving.pl
@@ -16,7 +16,7 @@
 # Start it
 $node_master->start;
 
-# Take backup for slave
+# Take backup for standby
 $node_master->backup($backup_name);
 
 # Initialize standby node from backup, fetching WAL from archives
diff --git a/src/test/recovery/t/005_replay_delay.pl b/src/test/recovery/t/005_replay_delay.pl
@@ -40,7 +40,7 @@
 	"INSERT INTO tab_int VALUES (generate_series(11, 20))");
 
 # Now wait for replay to complete on standby. We're done waiting when the
-# slave has replayed up to the previously saved master LSN.
+# standby has replayed up to the previously saved master LSN.
 my $until_lsn =
   $node_master->safe_psql('postgres', "SELECT pg_current_wal_lsn()");
 
diff --git a/src/test/recovery/t/009_twophase.pl b/src/test/recovery/t/009_twophase.pl
diff --git a/src/test/recovery/t/012_subtransactions.pl b/src/test/recovery/t/012_subtransactions.pl

Original file line number	Diff line number	Diff line change
`@@ -621,7 +621,7 @@ CommitTsParameterChange(bool newvalue, bool oldvalue)`
`621`	`621`	`*`
`622`	`622`	`* The reason why this SLRU needs separate activation/deactivation functions is`
`623`	`623`	`* that it can be enabled/disabled during start and the activation/deactivation`
`624`		`- * on master is propagated to slave via replay. Other SLRUs don't have this`
	`624`	`+ * on master is propagated to standby via replay. Other SLRUs don't have this`
`625`	`625`	`* property and they can be just initialized during normal startup.`
`626`	`626`	`*`
`627`	`627`	`* This is in charge of creating the currently active segment, if it's not`
Original file line number	Diff line number	Diff line change
`@@ -67,7 +67,7 @@ GetNewTransactionId(bool isSubXact)`
`67`	`67`	`return BootstrapTransactionId;`
`68`	`68`	`}`
`69`	`69`
`70`		`- /* safety check, we should never get this far in a HS slave */`
	`70`	`+ /* safety check, we should never get this far in a HS standby */`
`71`	`71`	`if (RecoveryInProgress())`
`72`	`72`	`elog(ERROR, "cannot assign TransactionIds during recovery");`
`73`	`73`
`@@ -468,7 +468,7 @@ GetNewObjectId(void)`
`468`	`468`	`{`
`469`	`469`	`Oid result;`
`470`	`470`
`471`		`- /* safety check, we should never get this far in a HS slave */`
	`471`	`+ /* safety check, we should never get this far in a HS standby */`
`472`	`472`	`if (RecoveryInProgress())`
`473`	`473`	`elog(ERROR, "cannot assign OIDs during recovery");`
`474`	`474`