/*
* mask_lp_flags
*
- * In some index AMs, line pointer flags can be modified in master without
- * emitting any WAL record.
+ * In some index AMs, line pointer flags can be modified on the primary
+ * without emitting any WAL record.
*/
void
mask_lp_flags(Page page)
* RecentGlobalXmin test in gistPageRecyclable() conceptually mirrors the
* pgxact->xmin > limitXmin test in GetConflictingVirtualXIDs().
* Consequently, one XID value achieves the same exclusion effect on
- * master and standby.
+ * primary and standby.
*/
if (InHotStandby)
{
* visible to everyone, we can skip the per-tuple visibility tests.
*
* Note: In hot standby, a tuple that's already visible to all
- * transactions in the master might still be invisible to a read-only
+ * transactions on the primary might still be invisible to a read-only
* transaction in the standby. We partly handle this problem by tracking
* the minimum xmin of visible tuples as the cut-off XID while marking a
- * page all-visible on master and WAL log that along with the visibility
+ * page all-visible on the primary and WAL log that along with the visibility
* map SET operation. In hot standby, we wait for (or abort) all
* transactions that can potentially may not see one or more tuples on the
* page. That's how index-only scans work fine in hot standby. A crucial
* updated/deleted by the inserting transaction.
*
* Look for a committed hint bit, or if no xmin bit is set, check clog.
- * This needs to work on both master and standby, where it is used to
+ * This needs to work on both primary and standby, where it is used to
* assess btree delete records.
*/
if (HeapTupleHeaderXminCommitted(tuple) ||
* tuples being deleted.
*
* We used to do this during recovery rather than on the primary, but that
- * approach now appears inferior. It meant that the master could generate
+ * approach now appears inferior. It meant that the primary could generate
* a lot of work for the standby without any back-pressure to slow down the
- * master, and it required the standby to have reached consistency, whereas
+ * primary, and it required the standby to have reached consistency, whereas
* we want to have correct information available even before that point.
*
* It's possible for this to generate a fair amount of I/O, since we may be
*
* During redo, heap_xlog_insert() sets t_ctid to current block
* number and self offset number. It doesn't care about any
- * speculative insertions in master. Hence, we set t_ctid to
+ * speculative insertions on the primary. Hence, we set t_ctid to
* current block number and self offset number to ignore any
* inconsistency.
*/
/*
* We can't write WAL in recovery mode, so there's no point trying to
- * clean the page. The master will likely issue a cleaning WAL record soon
+ * clean the page. The primary will likely issue a cleaning WAL record soon
* anyway, so this is no particular loss.
*/
if (RecoveryInProgress())
During recovery all index scans start with ignore_killed_tuples = false
and we never set kill_prior_tuple. We do this because the oldest xmin
-on the standby server can be older than the oldest xmin on the master
+on the standby server can be older than the oldest xmin on the primary
server, which means tuples can be marked LP_DEAD even when they are
still visible on the standby. We don't WAL log tuple LP_DEAD bits, but
they can still appear in the standby because of full page writes. So
* RecentGlobalXmin test in _bt_page_recyclable() conceptually mirrors the
* pgxact->xmin > limitXmin test in GetConflictingVirtualXIDs().
* Consequently, one XID value achieves the same exclusion effect on
- * master and standby.
+ * primary and standby.
*/
if (InHotStandby)
{
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("could not get commit timestamp data"),
RecoveryInProgress() ?
- errhint("Make sure the configuration parameter \"%s\" is set on the master server.",
+ errhint("Make sure the configuration parameter \"%s\" is set on the primary server.",
"track_commit_timestamp") :
errhint("Make sure the configuration parameter \"%s\" is set.",
"track_commit_timestamp")));
{
/*
* If the commit_ts module is disabled in this server and we get word from
- * the master server that it is enabled there, activate it so that we can
+ * the primary server that it is enabled there, activate it so that we can
* replay future WAL records involving it; also mark it as active on
* pg_control. If the old value was already set, we already did this, so
* don't do anything.
*
- * If the module is disabled in the master, disable it here too, unless
+ * If the module is disabled in the primary, disable it here too, unless
* the module is enabled locally.
*
* Note this only runs in the recovery process, so an unlocked read is
* Activate this module whenever necessary.
* This must happen during postmaster or standalone-backend startup,
* or during WAL replay anytime the track_commit_timestamp setting is
- * changed in the master.
+ * changed in the primary.
*
* 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 standby via replay. Other SLRUs don't have this
- * property and they can be just initialized during normal startup.
+ * on the primary is propagated to the 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
* already there. The reason for this is that the server might have been
/* Buffers dedicated to consistency checks of size BLCKSZ */
static char *replay_image_masked = NULL;
-static char *master_image_masked = NULL;
+static char *primary_image_masked = NULL;
/* options formerly taken from recovery.conf for archive recovery */
char *recoveryRestoreCommand = NULL;
XLOG_FROM_ANY = 0, /* request to read WAL from any source */
XLOG_FROM_ARCHIVE, /* restored using restore_command */
XLOG_FROM_PG_WAL, /* existing file in pg_wal */
- XLOG_FROM_STREAM /* streamed from master */
+ XLOG_FROM_STREAM /* streamed from primary */
} XLogSource;
/* human-readable names for XLogSources, for debugging output */
* page here, a local buffer is fine to hold its contents and a mask
* can be directly applied on it.
*/
- if (!RestoreBlockImage(record, block_id, master_image_masked))
+ if (!RestoreBlockImage(record, block_id, primary_image_masked))
elog(ERROR, "failed to restore block image");
/*
- * If masking function is defined, mask both the master and replay
+ * If masking function is defined, mask both the primary and replay
* images
*/
if (RmgrTable[rmid].rm_mask != NULL)
{
RmgrTable[rmid].rm_mask(replay_image_masked, blkno);
- RmgrTable[rmid].rm_mask(master_image_masked, blkno);
+ RmgrTable[rmid].rm_mask(primary_image_masked, blkno);
}
- /* Time to compare the master and replay images. */
- if (memcmp(replay_image_masked, master_image_masked, BLCKSZ) != 0)
+ /* Time to compare the primary and replay images. */
+ if (memcmp(replay_image_masked, primary_image_masked, BLCKSZ) != 0)
{
elog(FATAL,
"inconsistent page found, rel %u/%u/%u, forknum %u, blkno %u",
* a) we keep WAL for only one checkpoint cycle (prior to PG11 we kept
* WAL for two checkpoint cycles to allow us to recover from the
* secondary checkpoint if the first checkpoint failed, though we
- * only did this on the master anyway, not on standby. Keeping just
+ * only did this on the primary anyway, not on standby. Keeping just
* one checkpoint simplifies processing and reduces disk space in
* many smaller databases.)
* b) during checkpoint, we consume checkpoint_completion_target *
* however, unless we actually find a valid segment. That way if there is
* neither a timeline history file nor a WAL segment in the archive, and
* streaming replication is set up, we'll read the timeline history file
- * streamed from the master when we start streaming, instead of recovering
+ * streamed from the primary when we start streaming, instead of recovering
* with a dummy history generated here.
*/
if (expectedTLEs)
/*
* When recovery_min_apply_delay is set, we wait long enough to make sure
- * certain record types are applied at least that interval behind the master.
+ * certain record types are applied at least that interval behind the primary.
*
* Returns true if we waited.
*
if ((currValue) < (minValue)) \
ereport(ERROR, \
(errcode(ERRCODE_INVALID_PARAMETER_VALUE), \
- errmsg("hot standby is not possible because %s = %d is a lower setting than on the master server (its value was %d)", \
+ errmsg("hot standby is not possible because %s = %d is a lower setting than on the primary server (its value was %d)", \
param_name, \
currValue, \
minValue))); \
{
if (ControlFile->wal_level < WAL_LEVEL_REPLICA)
ereport(ERROR,
- (errmsg("hot standby is not possible because wal_level was not set to \"replica\" or higher on the master server"),
- errhint("Either set wal_level to \"replica\" on the master, or turn off hot_standby here.")));
+ (errmsg("hot standby is not possible because wal_level was not set to \"replica\" or higher on the primary server"),
+ errhint("Either set wal_level to \"replica\" on the primary, or turn off hot_standby here.")));
/* We ignore autovacuum_max_workers when we make this test. */
RecoveryRequiresIntParameter("max_connections",
* alignment, whereas palloc() will provide MAXALIGN'd storage.
*/
replay_image_masked = (char *) palloc(BLCKSZ);
- master_image_masked = (char *) palloc(BLCKSZ);
+ primary_image_masked = (char *) palloc(BLCKSZ);
if (read_backup_label(&checkPointLoc, &backupEndRequired,
&backupFromStandby))
* know how far we need to replay the WAL before we reach consistency.
* This can happen for example if a base backup is taken from a
* running server using an atomic filesystem snapshot, without calling
- * pg_start/stop_backup. Or if you just kill a running master server
+ * pg_start/stop_backup. Or if you just kill a running primary server
* and put it into archive recovery by creating a recovery signal
* file.
*
* ourselves - the history file of the recovery target timeline covers all
* the previous timelines in the history too - a cascading standby server
* might be interested in them. Or, if you archive the WAL from this
- * server to a different archive than the master, it'd be good for all the
+ * server to a different archive than the primary, it'd be good for all the
* history files to get archived there after failover, so that you can use
* one of the old timelines as a PITR target. Timeline history files are
* small, so it's better to copy them unnecessarily than not copy them and
/*
* If we're beginning at a shutdown checkpoint, we know that
- * nothing was running on the master at this point. So fake-up an
+ * nothing was running on the primary at this point. So fake-up an
* empty running-xacts record and use that here and now. Recover
* additional standby state for prepared transactions.
*/
}
/*
- * If we've been asked to lag the master, wait on latch until
+ * If we've been asked to lag the primary, wait on latch until
* enough time has passed.
*/
if (recoveryApplyDelay(xlogreader))
/*
* If rm_redo called XLogRequestWalReceiverReply, then we wake
* up the receiver so that it notices the updated
- * lastReplayedEndRecPtr and sends a reply to the master.
+ * lastReplayedEndRecPtr and sends a reply to the primary.
*/
if (doRequestWalReceiverReply)
{
/*
* If we see a shutdown checkpoint, we know that nothing was running
- * on the master at this point. So fake-up an empty running-xacts
+ * on the primary at this point. So fake-up an empty running-xacts
* record and use that here and now. Recover additional standby state
* for prepared transactions.
*/
"since last restartpoint"),
errhint("This means that the backup being taken on the standby "
"is corrupt and should not be used. "
- "Enable full_page_writes and run CHECKPOINT on the master, "
+ "Enable full_page_writes and run CHECKPOINT on the primary, "
"and then try an online backup again.")));
/*
appendStringInfo(labelfile, "BACKUP METHOD: %s\n",
exclusive ? "pg_start_backup" : "streamed");
appendStringInfo(labelfile, "BACKUP FROM: %s\n",
- backup_started_in_recovery ? "standby" : "master");
+ backup_started_in_recovery ? "standby" : "primary");
appendStringInfo(labelfile, "START TIME: %s\n", strfbuf);
appendStringInfo(labelfile, "LABEL: %s\n", backupidstr);
appendStringInfo(labelfile, "START TIMELINE: %u\n", starttli);
"during online backup"),
errhint("This means that the backup being taken on the standby "
"is corrupt and should not be used. "
- "Enable full_page_writes and run CHECKPOINT on the master, "
+ "Enable full_page_writes and run CHECKPOINT on the primary, "
"and then try an online backup again.")));
Assert(readFile != -1);
/*
- * If the current segment is being streamed from master, calculate how
+ * If the current segment is being streamed from the primary, calculate how
* much of the current page we have received already. We know the
* requested record has been received, but this is for the benefit of
* future calls, to allow quick exit at the top of this function.
* example, imagine a scenario where a streaming replica is started up,
* and replay reaches a record that's split across two WAL segments. The
* first page is only available locally, in pg_wal, because it's already
- * been recycled in the master. The second page, however, is not present
- * in pg_wal, and we should stream it from the master. There is a recycled
+ * been recycled on the primary. The second page, however, is not present
+ * in pg_wal, and we should stream it from the primary. There is a recycled
* WAL segment present in pg_wal, with garbage contents, however. We would
* read the first page from the local WAL segment, but when reading the
* second page, we would read the bogus, recycled, WAL segment. If we
* Failure while streaming. Most likely, we got here
* because streaming replication was terminated, or
* promotion was triggered. But we also get here if we
- * find an invalid record in the WAL streamed from master,
+ * find an invalid record in the WAL streamed from the primary,
* in which case something is seriously wrong. There's
* little chance that the problem will just go away, but
* PANIC is not good for availability either, especially
* we're retrying the exact same record that we've tried previously, only
* complain the first time to keep the noise down. However, we only do when
* reading from pg_wal, because we don't expect any invalid records in archive
- * or in records streamed from master. Files in the archive should be complete,
+ * or in records streamed from the primary. Files in the archive should be complete,
* and we should never hit the end of WAL because we stop and wait for more WAL
* to arrive before replaying it.
*
*
* We care about timelines in xlogreader when we might be reading xlog
* generated prior to a promotion, either if we're currently a standby in
- * recovery or if we're a promoted master reading xlogs generated by the old
- * master before our promotion.
+ * recovery or if we're a promoted primary reading xlogs generated by the old
+ * primary before our promotion.
*
* wantPage must be set to the start address of the page to read and
* wantLength to the amount of the page that will be read, up to
* we actually read the xlog page, we might still try to read from the
* old (now renamed) segment and fail. There's not much we can do
* about this, but it can only happen when we're a leaf of a cascading
- * standby whose master gets promoted while we're decoding, so a
+ * standby whose primary gets promoted while we're decoding, so a
* one-off ERROR isn't too bad.
*/
XLogReadDetermineTimeline(state, targetPagePtr, reqLen);
* 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 hot standby session with the same BackendId. We
+ * primary, 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;
* and does not travel through this section of code and cannot be combined with
* any of the subcommands given here.
*
- * Note that Hot Standby only knows about AccessExclusiveLocks on the master
+ * Note that Hot Standby only knows about AccessExclusiveLocks on the primary
* so any changes that might affect SELECTs running on standbys need to use
* AccessExclusiveLocks even if you think a lesser lock would do, unless you
* have a solution for that also.
* only during a few moments during a standby promotion. However there is
* a race condition: if pg_ctl promote is executed and creates the files
* during a promotion, the files can stay around even after the server is
- * brought up to new master. Then, if new standby starts by using the
- * backup taken from that master, the files can exist at the server
+ * brought up to be the primary. Then, if a new standby starts by using the
+ * backup taken from the new primary, the files can exist at the server
* startup and should be removed in order to avoid an unexpected
* promotion.
*
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.
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.
/*
* 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",
}
/*
- * 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.
*/
* 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;
/*
* 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
if (len > 0)
{
/*
- * Something was received from master, so reset
+ * Something was received from primary, so reset
* timeout
*/
last_recv_timestamp = GetCurrentTimestamp();
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);
/*
* 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;
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.
*/
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);
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)
* 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.
*/
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. */
* 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.
*/
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;
}
/*
*
* 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
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();
}
*
* 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
* at need by checking for pid == 0.
*
* During hot standby, we also keep a list of XIDs representing transactions
- * that are known to be running in the master (or more precisely, were running
+ * that are known to be running on the primary (or more precisely, were running
* as of the current point in the WAL stream). This list is kept in the
* KnownAssignedXids array, and is updated by watching the sequence of
* arriving XIDs. This is necessary because if we leave those XIDs out of
* array represents standby processes, which by definition are not running
* transactions that have XIDs.
*
- * It is perhaps possible for a backend on the master to terminate without
+ * It is perhaps possible for a backend on the primary to terminate without
* writing an abort record for its transaction. While that shouldn't really
* happen, it would tie up KnownAssignedXids indefinitely, so we protect
* ourselves by pruning the array when a valid list of running XIDs arrives.
* Normal case is to go all the way to Ready straight away, though there
* are atypical cases where we need to take it in steps.
*
- * Use the data about running transactions on master to create the initial
+ * Use the data about running transactions on the primary to create the initial
* state of KnownAssignedXids. We also use these records to regularly prune
* KnownAssignedXids because we know it is possible that some transactions
* with FATAL errors fail to write abort records, which could cause eventual
* We can find this out cheaply too.
*
* 3. In Hot Standby mode, we must search the KnownAssignedXids list to see
- * if the Xid is running on the master.
+ * if the Xid is running on the primary.
*
* 4. Search the SubTrans tree to find the Xid's topmost parent, and then see
* if that is running according to PGXACT or KnownAssignedXids. This is the
* TransactionIdIsActive -- is xid the top-level XID of an active backend?
*
* This differs from TransactionIdIsInProgress in that it ignores prepared
- * transactions, as well as transactions running on the master if we're in
+ * transactions, as well as transactions running on the primary if we're in
* hot standby. Also, we ignore subtransactions since that's not needed
* for current uses.
*/
* Nonetheless it is safe to vacuum a table in the current database with the
* first result. There are also replication-related effects: a walsender
* process can set its xmin based on transactions that are no longer running
- * in the master but are still being replayed on the standby, thus possibly
+ * on the primary but are still being replayed on the standby, thus possibly
* making the GetOldestXmin reading go backwards. In this case there is a
* possibility that we lose data that the standby would like to have, but
* unless the standby uses a replication slot to make its xmin persistent
*
* vacuum_defer_cleanup_age provides some additional "slop" for the
* benefit of hot standby queries on standby servers. This is quick
- * and dirty, and perhaps not all that useful unless the master has a
+ * and dirty, and perhaps not all that useful unless the primary has a
* predictable transaction rate, but it offers some protection when
* there's no walsender connection. Note that we are assuming
* vacuum_defer_cleanup_age isn't large enough to cause wraparound ---
/*
* In Hot Standby mode, we maintain a list of transactions that are (or were)
- * running in the master at the current point in WAL. These XIDs must be
+ * running on the primary at the current point in WAL. These XIDs must be
* treated as running by standby transactions, even though they are not in
* the standby server's PGXACT array.
*
* links are *not* maintained (which does not affect visibility).
*
* We have room in KnownAssignedXids and in snapshots to hold maxProcs *
- * (1 + PGPROC_MAX_CACHED_SUBXIDS) XIDs, so every master transaction must
+ * (1 + PGPROC_MAX_CACHED_SUBXIDS) XIDs, so every primary transaction must
* report its subtransaction XIDs in a WAL XLOG_XACT_ASSIGNMENT record at
* least every PGPROC_MAX_CACHED_SUBXIDS. When we receive one of these
* records, we mark the subXIDs as children of the top XID in pg_subtrans,
* order, to be exact --- to allow binary search for specific XIDs. Note:
* in general TransactionIdPrecedes would not provide a total order, but
* we know that the entries present at any instant should not extend across
- * a large enough fraction of XID space to wrap around (the master would
+ * a large enough fraction of XID space to wrap around (the primary would
* shut down for fear of XID wrap long before that happens). So it's OK to
* use TransactionIdPrecedes as a binary-search comparator.
*
/*
* InitRecoveryTransactionEnvironment
- * Initialize tracking of in-progress transactions in master
+ * Initialize tracking of our primary's in-progress transactions.
*
* We need to issue shared invalidations and hold locks. Holding locks
* means others may want to wait on us, so we need to make a lock table
not be concerned that a user initiated deadlock can prevent recovery from
progressing.
-AccessExclusiveLocks on the primary or master node generate WAL records
+AccessExclusiveLocks on the primary node generate WAL records
that are then applied by the Startup process. Locks are released at end
of transaction just as they are in normal processing. These locks are
held by the Startup process, acting as a proxy for the backends that
checksums are enabled. Systems in Hot-Standby mode may benefit from hint bits
being set, but with checksums enabled, a page cannot be dirtied after setting a
hint bit (due to the torn page risk). So, it must wait for full-page images
-containing the hint bit updates to arrive from the master.
+containing the hint bit updates to arrive from the primary.
gettext_noop("Replication"),
/* REPLICATION_SENDING */
gettext_noop("Replication / Sending Servers"),
- /* REPLICATION_MASTER */
- gettext_noop("Replication / Master Server"),
+ /* REPLICATION_PRIMARY */
+ gettext_noop("Replication / Primary Server"),
/* REPLICATION_STANDBY */
gettext_noop("Replication / Standby Servers"),
/* REPLICATION_SUBSCRIBERS */
},
{
- {"vacuum_defer_cleanup_age", PGC_SIGHUP, REPLICATION_MASTER,
+ {"vacuum_defer_cleanup_age", PGC_SIGHUP, REPLICATION_PRIMARY,
gettext_noop("Number of transactions by which VACUUM and HOT cleanup should be deferred, if any."),
NULL
},
},
{
- {"synchronous_standby_names", PGC_SIGHUP, REPLICATION_MASTER,
+ {"synchronous_standby_names", PGC_SIGHUP, REPLICATION_PRIMARY,
gettext_noop("Number of synchronous standbys and list of names of potential synchronous ones."),
NULL,
GUC_LIST_INPUT
# - Sending Servers -
-# Set these on the master and on any standby that will send replication data.
+# Set these on the primary and on any standby that will send replication data.
#max_wal_senders = 10 # max number of walsender processes
# (change requires restart)
#track_commit_timestamp = off # collect timestamp of transaction commit
# (change requires restart)
-# - Master Server -
+# - Primary Server -
# These settings are ignored on a standby server.
# - Standby Servers -
-# These settings are ignored on a master server.
+# These settings are ignored on a primary server.
#primary_conninfo = '' # connection string to sending server
#primary_slot_name = '' # replication slot on sending server
#hot_standby_feedback = off # send info from standby to prevent
# query conflicts
#wal_receiver_timeout = 60s # time that receiver waits for
- # communication from master
+ # communication from primary
# in milliseconds; 0 disables
#wal_retrieve_retry_interval = 5s # time to wait before retrying to
# retrieve WAL after a failed attempt
}
/*
- * Potentially send a status message to the master
+ * Potentially send a status message to the primary.
*/
now = feGetCurrentTimestamp();
* race-y since a signal received while busy won't interrupt the wait.
*
* standby_message_timeout controls how often we send a message
- * back to the master letting it know our progress, in milliseconds.
+ * back to the primary letting it know our progress, in milliseconds.
* Zero means no messages are sent.
* This message will only contain the write location, and never
* flush or replay.
}
/*
- * Potentially send a status message to the master
+ * Potentially send a status message to the primary
*/
if (still_sending && stream->standby_message_timeout > 0 &&
feTimestampDifferenceExceeds(last_status, now,
if (errno == ENOENT)
{
/*
- * File doesn't exist anymore. This is ok, if the new master
+ * File doesn't exist anymore. This is ok, if the new primary
* is running and the file was just removed. If it was a data
* file, there should be a WAL record of the removal. If it
* was something else, it couldn't have been anyway.
/*
* 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",
/*
* Check if it is a checkpoint record. This checkpoint record needs to
* be the latest checkpoint before WAL forked and not the checkpoint
- * where the master has been stopped to be rewinded.
+ * where the primary has been stopped to be rewinded.
*/
info = XLogRecGetInfo(xlogreader) & ~XLR_INFO_MASK;
if (searchptr < forkptr &&
*
* In INITIALIZED state, we've run InitRecoveryTransactionEnvironment, but
* we haven't yet processed a RUNNING_XACTS or shutdown-checkpoint WAL record
- * to initialize our master-transaction tracking system.
+ * to initialize our primary-transaction tracking system.
*
* When the transaction tracking is initialized, we enter the SNAPSHOT_PENDING
* state. The tracked information might still be incomplete, so we can't allow
* appropriate.
*
* In SNAPSHOT_READY mode, we have full knowledge of transactions that are
- * (or were) running in the master at the current WAL location. Snapshots
+ * (or were) running on the primary at the current WAL location. Snapshots
* can be taken, and read-only queries can be run.
*/
typedef enum
*
* COMMAND_OK_IN_RECOVERY means that the command is permissible even when in
* recovery. It can't write WAL, nor can it do things that would imperil
- * replay of future WAL received from the master.
+ * replay of future WAL received from the primary.
*/
#define COMMAND_OK_IN_READ_ONLY_TXN 0x0001
#define COMMAND_OK_IN_PARALLEL_MODE 0x0002
WAL_RECOVERY_TARGET,
REPLICATION,
REPLICATION_SENDING,
- REPLICATION_MASTER,
+ REPLICATION_PRIMARY,
REPLICATION_STANDBY,
REPLICATION_SUBSCRIBERS,
QUERY_TUNING,
projects / postgresql.git / commitdiff