diff options
Diffstat (limited to 'src/backend/replication')
| -rw-r--r-- | src/backend/replication/README | 6 | ||||
| -rw-r--r-- | src/backend/replication/basebackup.c | 2 | ||||
| -rw-r--r-- | src/backend/replication/logical/worker.c | 4 | ||||
| -rw-r--r-- | src/backend/replication/walreceiver.c | 32 | ||||
| -rw-r--r-- | src/backend/replication/walsender.c | 8 |
5 files changed, 26 insertions, 26 deletions
diff --git a/src/backend/replication/README b/src/backend/replication/README index eae6ca729f4..8fcd78da9aa 100644 --- a/src/backend/replication/README +++ b/src/backend/replication/README @@ -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. diff --git a/src/backend/replication/basebackup.c b/src/backend/replication/basebackup.c index 096b0fcef0d..6064384e32a 100644 --- a/src/backend/replication/basebackup.c +++ b/src/backend/replication/basebackup.c @@ -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", diff --git a/src/backend/replication/logical/worker.c b/src/backend/replication/logical/worker.c index a752a1224d6..f90a896fc3e 100644 --- a/src/backend/replication/logical/worker.c +++ b/src/backend/replication/logical/worker.c @@ -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; diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index d1ad75da87a..d5a9b568a68 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -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 diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c index e2477c47e0a..f66acb87206 100644 --- a/src/backend/replication/walsender.c +++ b/src/backend/replication/walsender.c @@ -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 |