diff options
| author | Fujii Masao | 2025-04-02 06:13:01 +0000 |
|---|---|---|
| committer | Fujii Masao | 2025-04-02 06:13:01 +0000 |
| commit | b53b88109f94bd81ed0ac580035a936000bc2865 (patch) | |
| tree | d6ca80d80d232207621553a395afd64f4ff81ce7 /src/backend/postmaster | |
| parent | 121d774caea4c93c8b36fb20a17ef774e60894d6 (diff) | |
Improve error message when standby does accept connections.
Even after reaching the minimum recovery point, if there are long-lived
write transactions with 64 subtransactions on the primary, the recovery
snapshot may not yet be ready for hot standby, delaying read-only
connections on the standby. Previously, when read-only connections were
not accepted due to this condition, the following error message was logged:
FATAL: the database system is not yet accepting connections
DETAIL: Consistent recovery state has not been yet reached.
This DETAIL message was misleading because the following message was
already logged in this case:
LOG: consistent recovery state reached
This contradiction, i.e., indicating that the recovery state was consistent
while also stating it wasn’t, caused confusion.
This commit improves the error message to better reflect the actual state:
FATAL: the database system is not yet accepting connections
DETAIL: Recovery snapshot is not yet ready for hot standby.
HINT: To enable hot standby, close write transactions with more than 64 subtransactions on the primary server.
To implement this, the commit introduces a new postmaster signal,
PMSIGNAL_RECOVERY_CONSISTENT. When the startup process reaches
a consistent recovery state, it sends this signal to the postmaster,
allowing it to correctly recognize that state.
Since this is not a clear bug, the change is applied only to the master
branch and is not back-patched.
Author: Atsushi Torikoshi <torikoshia@oss.nttdata.com>
Co-authored-by: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Yugo Nagata <nagata@sraoss.co.jp>
Discussion: https://postgr.es/m/02db8cd8e1f527a8b999b94a4bee3165@oss.nttdata.com
Diffstat (limited to 'src/backend/postmaster')
| -rw-r--r-- | src/backend/postmaster/postmaster.c | 12 |
1 files changed, 9 insertions, 3 deletions
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c index c966c2e83af..3fe45de5da0 100644 --- a/src/backend/postmaster/postmaster.c +++ b/src/backend/postmaster/postmaster.c @@ -1825,8 +1825,7 @@ canAcceptConnections(BackendType backend_type) else if (!FatalError && pmState == PM_STARTUP) return CAC_STARTUP; /* normal startup */ else if (!FatalError && pmState == PM_RECOVERY) - return CAC_NOTCONSISTENT; /* not yet at consistent recovery - * state */ + return CAC_NOTHOTSTANDBY; /* not yet ready for hot standby */ else return CAC_RECOVERY; /* else must be crash recovery */ } @@ -3699,6 +3698,7 @@ process_pm_pmsignal(void) /* WAL redo has started. We're out of reinitialization. */ FatalError = false; AbortStartTime = 0; + reachedConsistency = false; /* * Start the archiver if we're responsible for (re-)archiving received @@ -3724,9 +3724,15 @@ process_pm_pmsignal(void) UpdatePMState(PM_RECOVERY); } - if (CheckPostmasterSignal(PMSIGNAL_BEGIN_HOT_STANDBY) && + if (CheckPostmasterSignal(PMSIGNAL_RECOVERY_CONSISTENT) && pmState == PM_RECOVERY && Shutdown == NoShutdown) { + reachedConsistency = true; + } + + if (CheckPostmasterSignal(PMSIGNAL_BEGIN_HOT_STANDBY) && + (pmState == PM_RECOVERY && Shutdown == NoShutdown)) + { ereport(LOG, (errmsg("database system is ready to accept read-only connections"))); |