1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-10 17:42:29 +03:00

code: replace 'master' with 'primary' where appropriate.

Also changed "in the primary" to "on the primary", and added a few
"the" before "primary".

Author: Andres Freund
Reviewed-By: David Steele
Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
This commit is contained in:
Andres Freund
2020-06-14 14:05:18 -07:00
parent 229f8c219f
commit 5e7bbb5286
31 changed files with 110 additions and 110 deletions

View File

@@ -357,8 +357,8 @@ WalReceiverMain(void)
/*
* Get any missing history files. We do this always, even when we're
* not interested in that timeline, so that if we're promoted to
* become the master later on, we don't select the same timeline that
* was already used in the current master. This isn't bullet-proof -
* become the primary later on, we don't select the same timeline that
* was already used in the current primary. This isn't bullet-proof -
* you'll need some external software to manage your cluster if you
* need to ensure that a unique timeline id is chosen in every case,
* but let's avoid the confusion of timeline id collisions where we
@@ -464,7 +464,7 @@ WalReceiverMain(void)
if (len > 0)
{
/*
* Something was received from master, so reset
* Something was received from primary, so reset
* timeout
*/
last_recv_timestamp = GetCurrentTimestamp();
@@ -486,7 +486,7 @@ WalReceiverMain(void)
len = walrcv_receive(wrconn, &buf, &wait_fd);
}
/* Let the master know that we received some data. */
/* Let the primary know that we received some data. */
XLogWalRcvSendReply(false, false);
/*
@@ -545,7 +545,7 @@ WalReceiverMain(void)
* wal_receiver_timeout / 2, ping the server. Also, if
* it's been longer than wal_receiver_status_interval
* since the last update we sent, send a status update to
* the master anyway, to report any progress in applying
* the primary anyway, to report any progress in applying
* WAL.
*/
bool requestReply = false;
@@ -745,7 +745,7 @@ WalRcvFetchTimeLineHistoryFiles(TimeLineID first, TimeLineID last)
walrcv_readtimelinehistoryfile(wrconn, tli, &fname, &content, &len);
/*
* Check that the filename on the master matches what we
* Check that the filename on the primary matches what we
* calculated ourselves. This is just a sanity check, it should
* always match.
*/
@@ -1034,7 +1034,7 @@ XLogWalRcvFlush(bool dying)
set_ps_display(activitymsg);
}
/* Also let the master know that we made some progress */
/* Also let the primary know that we made some progress */
if (!dying)
{
XLogWalRcvSendReply(false, false);
@@ -1066,7 +1066,7 @@ XLogWalRcvSendReply(bool force, bool requestReply)
TimestampTz now;
/*
* If the user doesn't want status to be reported to the master, be sure
* If the user doesn't want status to be reported to the primary, be sure
* to exit before doing anything at all.
*/
if (!force && wal_receiver_status_interval <= 0)
@@ -1080,7 +1080,7 @@ XLogWalRcvSendReply(bool force, bool requestReply)
* sent without taking any lock, but the apply position requires a spin
* lock, so we don't check that unless something else has changed or 10
* seconds have passed. This means that the apply WAL location will
* appear, from the master's point of view, to lag slightly, but since
* appear, from the primary's point of view, to lag slightly, but since
* this is only for reporting purposes and only on idle systems, that's
* probably OK.
*/
@@ -1138,14 +1138,14 @@ XLogWalRcvSendHSFeedback(bool immed)
static TimestampTz sendTime = 0;
/* initially true so we always send at least one feedback message */
static bool master_has_standby_xmin = true;
static bool primary_has_standby_xmin = true;
/*
* If the user doesn't want status to be reported to the master, be sure
* If the user doesn't want status to be reported to the primary, be sure
* to exit before doing anything at all.
*/
if ((wal_receiver_status_interval <= 0 || !hot_standby_feedback) &&
!master_has_standby_xmin)
!primary_has_standby_xmin)
return;
/* Get current timestamp. */
@@ -1168,7 +1168,7 @@ XLogWalRcvSendHSFeedback(bool immed)
* calls.
*
* Bailing out here also ensures that we don't send feedback until we've
* read our own replication slot state, so we don't tell the master to
* read our own replication slot state, so we don't tell the primary to
* discard needed xmin or catalog_xmin from any slots that may exist on
* this replica.
*/
@@ -1230,9 +1230,9 @@ XLogWalRcvSendHSFeedback(bool immed)
pq_sendint32(&reply_message, catalog_xmin_epoch);
walrcv_send(wrconn, reply_message.data, reply_message.len);
if (TransactionIdIsValid(xmin) || TransactionIdIsValid(catalog_xmin))
master_has_standby_xmin = true;
primary_has_standby_xmin = true;
else
master_has_standby_xmin = false;
primary_has_standby_xmin = false;
}
/*
@@ -1291,7 +1291,7 @@ ProcessWalSndrMessage(XLogRecPtr walEnd, TimestampTz sendTime)
*
* This is called by the startup process whenever interesting xlog records
* are applied, so that walreceiver can check if it needs to send an apply
* notification back to the master which may be waiting in a COMMIT with
* notification back to the primary which may be waiting in a COMMIT with
* synchronous_commit = remote_apply.
*/
void