From ed3ea3fa0c02a88753c5a162a1fe94e67604b627 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Thu, 12 Aug 2010 23:25:45 +0000 Subject: Correct sundry errors in Hot Standby-related comments. Fujii Masao --- src/backend/storage/ipc/procarray.c | 20 ++++++++++---------- src/backend/storage/ipc/standby.c | 8 ++++---- 2 files changed, 14 insertions(+), 14 deletions(-) (limited to 'src/backend/storage') diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c index 9a1b148cd15..f5bb57446f9 100644 --- a/src/backend/storage/ipc/procarray.c +++ b/src/backend/storage/ipc/procarray.c @@ -37,7 +37,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/storage/ipc/procarray.c,v 1.72 2010/07/06 19:18:57 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/storage/ipc/procarray.c,v 1.72.2.1 2010/08/12 23:25:45 rhaas Exp $ * *------------------------------------------------------------------------- */ @@ -449,7 +449,7 @@ ProcArrayInitRecoveryInfo(TransactionId oldestActiveXid) /* * ProcArrayApplyRecoveryInfo -- apply recovery info about xids * - * Takes us through 3 states: Uninitialized, Pending and Ready. + * Takes us through 3 states: Initialized, Pending and Ready. * 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. * @@ -487,7 +487,7 @@ ProcArrayApplyRecoveryInfo(RunningTransactions running) return; /* - * If our initial RunningXactData had an overflowed snapshot then we knew + * If our initial RunningTransactionsData had an overflowed snapshot then we knew * we were missing some subxids from our snapshot. We can use this data as * an initial snapshot, but we cannot yet mark it valid. We know that the * missing subxids are equal to or earlier than nextXid. After we @@ -518,7 +518,7 @@ ProcArrayApplyRecoveryInfo(RunningTransactions running) Assert(standbyState == STANDBY_INITIALIZED); /* - * OK, we need to initialise from the RunningXactData record + * OK, we need to initialise from the RunningTransactionsData record */ /* @@ -1499,7 +1499,7 @@ GetRunningTransactionData(void) suboverflowed = true; /* - * Top-level XID of a transaction is always greater than any of + * Top-level XID of a transaction is always less than any of * its subxids, so we don't need to check if any of the subxids * are smaller than oldestRunningXid */ @@ -2313,7 +2313,7 @@ DisplayXidCache(void) * aborted but we think they were running; the distinction is irrelevant * because either way any changes done by the transaction are not visible to * backends in the standby. We prune KnownAssignedXids when - * XLOG_XACT_RUNNING_XACTS arrives, to forestall possible overflow of the + * XLOG_RUNNING_XACTS arrives, to forestall possible overflow of the * array due to such dead XIDs. */ @@ -2323,9 +2323,9 @@ DisplayXidCache(void) * unobserved XIDs. * * RecordKnownAssignedTransactionIds() should be run for *every* WAL record - * type apart from XLOG_XACT_RUNNING_XACTS (since that initialises the first + * type apart from XLOG_RUNNING_XACTS (since that initialises the first * snapshot so that RecordKnownAssignedTransactionIds() can be called). Must - * be called for each record after we have executed StartupCLog() et al, + * be called for each record after we have executed StartupCLOG() et al, * since we must ExtendCLOG() etc.. * * Called during recovery in analogy with and in place of GetNewTransactionId() @@ -3046,11 +3046,11 @@ KnownAssignedXidsDisplay(int trace_level) if (KnownAssignedXidsValid[i]) { nxids++; - appendStringInfo(&buf, "[%u]=%u ", i, KnownAssignedXids[i]); + appendStringInfo(&buf, "[%d]=%u ", i, KnownAssignedXids[i]); } } - elog(trace_level, "%d KnownAssignedXids (num=%u tail=%u head=%u) %s", + elog(trace_level, "%d KnownAssignedXids (num=%d tail=%d head=%d) %s", nxids, pArray->numKnownAssignedXids, pArray->tailKnownAssignedXids, diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c index d007f71041b..386e712e785 100644 --- a/src/backend/storage/ipc/standby.c +++ b/src/backend/storage/ipc/standby.c @@ -11,7 +11,7 @@ * Portions Copyright (c) 1994, Regents of the University of California * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/storage/ipc/standby.c,v 1.27 2010/07/06 19:18:57 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/storage/ipc/standby.c,v 1.27.2.1 2010/08/12 23:25:45 rhaas Exp $ * *------------------------------------------------------------------------- */ @@ -522,7 +522,7 @@ CheckRecoveryConflictDeadlock(LWLockId partitionLock) * one transaction on one relation, and don't worry about lock queuing. * * We keep a single dynamically expandible list of locks in local memory, - * RelationLockList, so we can keep track of the various entried made by + * RelationLockList, so we can keep track of the various entries made by * the Startup process's virtual xid in the shared lock table. * * List elements use type xl_rel_lock, since the WAL record type exactly @@ -700,7 +700,7 @@ standby_redo(XLogRecPtr lsn, XLogRecord *record) { uint8 info = record->xl_info & ~XLR_INFO_MASK; - /* Do nothing if we're not in standby mode */ + /* Do nothing if we're not in hot standby mode */ if (standbyState == STANDBY_DISABLED) return; @@ -872,7 +872,7 @@ LogStandbySnapshot(TransactionId *oldestActiveXid, TransactionId *nextXid) /* * Record an enhanced snapshot of running transactions into WAL. * - * The definitions of RunningTransactionData and xl_xact_running_xacts + * The definitions of RunningTransactionsData and xl_xact_running_xacts * are similar. We keep them separate because xl_xact_running_xacts * is a contiguous chunk of memory and never exists fully until it is * assembled in WAL. -- cgit v1.2.3