database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-28 18:48:04 +03:00
Code Activity

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

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

6
src/backend/replication/README
View File

@@ -28,11 +28,11 @@ it. Before that, however, startup process fills in WalRcvData->conninfo
and WalRcvData->slotname, and initializes the starting point in
WalRcvData->receiveStart.
As walreceiver receives WAL from the master server, and writes and flushes
As walreceiver receives WAL from the primary server, and writes and flushes
it to disk (in pg_wal), it updates WalRcvData->flushedUpto and signals
the startup process to know how far WAL replay can advance.
Walreceiver sends information about replication progress to the master server
Walreceiver sends information about replication progress to the primary server
whenever it either writes or flushes new WAL, or the specified interval elapses.
This is used for reporting purpose.
@@ -43,7 +43,7 @@ At shutdown, postmaster handles walsender processes differently from regular
backends. It waits for regular backends to die before writing the
shutdown checkpoint and terminating pgarch and other auxiliary processes, but
that's not desirable for walsenders, because we want the standby servers to
receive all the WAL, including the shutdown checkpoint, before the master
receive all the WAL, including the shutdown checkpoint, before the primary
is shut down. Therefore postmaster treats walsenders like the pgarch process,
and instructs them to terminate at PM_SHUTDOWN_2 phase, after all regular
backends have died and checkpointer has issued the shutdown checkpoint.

2
src/backend/replication/basebackup.c
View File

@@ -161,7 +161,7 @@ static const char *const excludeDirContents[] =
/*
* It is generally not useful to backup the contents of this directory
* even if the intention is to restore to another master. See backup.sgml
* even if the intention is to restore to another primary. See backup.sgml
* for a more detailed description.
*/
"pg_replslot",

4
src/backend/replication/logical/worker.c
View File

@@ -1312,7 +1312,7 @@ apply_handle_truncate(StringInfo s)
}
/*
* Even if we used CASCADE on the upstream master we explicitly default to
* Even if we used CASCADE on the upstream primary we explicitly default to
* replaying changes without further cascading. This might be later
* changeable with a user specified option.
*/
@@ -1661,7 +1661,7 @@ LogicalRepApplyLoop(XLogRecPtr last_received)
* from the server for more than 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
* send a status update to the primary anyway, to report any
* progress in applying WAL.
*/
bool requestReply = false;

32
src/backend/replication/walreceiver.c
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

8
src/backend/replication/walsender.c
View File

@@ -2628,14 +2628,14 @@ XLogSendPhysical(void)
else
{
/*
* Streaming the current timeline on a master.
* Streaming the current timeline on a primary.
*
* Attempt to send all data that's already been written out and
* fsync'd to disk. We cannot go further than what's been written out
* given the current implementation of WALRead(). 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, standbys
* must not have applied any WAL that got lost on the master.
* primary: if the primary subsequently crashes and restarts, standbys
* must not have applied any WAL that got lost on the primary.
*/
SendRqstPtr = GetFlushRecPtr();
}
@@ -2672,7 +2672,7 @@ XLogSendPhysical(void)
*
* Note: We might already have sent WAL > sendTimeLineValidUpto. The
* startup process will normally replay all WAL that has been received
* from the master, before promoting, but if the WAL streaming is
* from the primary, before promoting, but if the WAL streaming is
* terminated at a WAL page boundary, the valid portion of the timeline
* might end in the middle of a WAL record. We might've already sent the
* first half of that partial WAL record to the cascading standby, so that