From 908db07687d9d4473ab86d93356b7d605329c0be Mon Sep 17 00:00:00 2001 From: Atsushi Torikoshi Date: Thu, 27 Mar 2025 23:50:08 +0900 Subject: [PATCH v4] Modify and log to align with the doc There is an inconsistency between the documentation[1] and the log messages regarding the definition of a 'consistent' recovery state. The documentation states that a consistent state requires both that recovery has progressed beyond minRecoveryPoint and that there are no overflowed subtransactions, whereas the source code previously considered only minRecoveryPoint. This patch modifies and adds log messages to align with the documentation. Specifically, messages are now logged both when recovery progresses beyond minRecoveryPoint and when the system reaches a consistent state in the updated definition. As a result, the "consistent recovery state reached" message is now output later than before. As a side effect, previously, if hot standby remained inaccessible due to overflowed subtransactions, it was difficult to determine the cause. With this change in log messages and the corresponding update to the documentation, the reason for the delay can now be identified more clearly. [1] https://www.postgresql.org/docs/devel/hot-standby.html --- doc/src/sgml/high-availability.sgml | 8 ++++++++ src/backend/access/transam/xlogrecovery.c | 5 ++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index acf3ac0601..c83c5403ed 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1967,6 +1967,10 @@ LOG: entering standby mode ... then some time later ... +LOG: minimum recovery point reached + +... It may take some time ... + LOG: consistent recovery state reached LOG: database system is ready to accept read-only connections @@ -1991,6 +1995,10 @@ LOG: database system is ready to accept read-only connections + In this case, only "minimum recovery point reached" is logged, and + "consistent recovery state reached" is not logged. This issue can be + resolved by closing the transaction. + This case can be resolved by closing the transaction. If you are running file-based log shipping ("warm standby"), you might need to wait until the next WAL file arrives, which could be as long as the archive_timeout setting on the primary. diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c index 2c19013c98..8152f90c99 100644 --- a/src/backend/access/transam/xlogrecovery.c +++ b/src/backend/access/transam/xlogrecovery.c @@ -2249,7 +2249,7 @@ CheckRecoveryConsistency(void) reachedConsistency = true; ereport(LOG, - (errmsg("consistent recovery state reached at %X/%X", + (errmsg("minimum recovery point reached at %X/%X", LSN_FORMAT_ARGS(lastReplayedEndRecPtr)))); } @@ -2268,6 +2268,9 @@ CheckRecoveryConsistency(void) SpinLockRelease(&XLogRecoveryCtl->info_lck); LocalHotStandbyActive = true; + ereport(LOG, + (errmsg("consistent recovery state reached at %X/%X", + LSN_FORMAT_ARGS(lastReplayedEndRecPtr)))); SendPostmasterSignal(PMSIGNAL_BEGIN_HOT_STANDBY); } base-commit: 0f3604a518f8b3fd35ffc344d85c71693ded0dde -- 2.48.1