From d2eb01a10b07d10e1a3fee2150862986dc0edf41 Mon Sep 17 00:00:00 2001 From: Atsushi Torikoshi Date: Mon, 24 Mar 2025 23:13:52 +0900 Subject: [PATCH v2] Change log message when hot standby is not accessible Previously, the log message only assumed that the recovery process had not yet reached a consistent point. However, even when we have reached the consistent point, if there is a transaction whose subtransaction is overflowed, the hot standby is not accessible and it was difficult to identify the cause since there are no log message indicates the reason. This change improves clarity by explicitly mention the case. Additionally, the documentation has been updated to clarify that overflowed subtransactions can delay snapshot readiness for hot standby and hot to solve it. --- doc/src/sgml/high-availability.sgml | 7 +++++-- src/backend/postmaster/postmaster.c | 6 ++++-- src/backend/tcop/backend_startup.c | 4 ++-- src/include/tcop/backend_startup.h | 2 +- 4 files changed, 12 insertions(+), 7 deletions(-) diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index acf3ac0601..6e336b1a8e 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1535,8 +1535,11 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)' When the parameter is set to true on a standby server, it will begin accepting connections once the recovery has - brought the system to a consistent state. All such connections are - strictly read-only; not even temporary tables may be written. + brought the system to a consistent state. However, overflowed + subtransactions may also delay snapshot readiness for hot standby. In such + case, the issue can be resolved by closing the transaction containing the + overflowed subtransactions. All connections accepted by the hot standby + are strictly read-only; not even temporary tables may be written. diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c index a0c37532d2..6c678af8e6 100644 --- a/src/backend/postmaster/postmaster.c +++ b/src/backend/postmaster/postmaster.c @@ -1825,8 +1825,10 @@ 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_NOTCONSISTENT_OR_OVERFLOWED; /* not yet at consistent + * recovery state or + * subtransaction is + * overflowed */ else return CAC_RECOVERY; /* else must be crash recovery */ } diff --git a/src/backend/tcop/backend_startup.c b/src/backend/tcop/backend_startup.c index 27c0b3c2b0..37ba5f760e 100644 --- a/src/backend/tcop/backend_startup.c +++ b/src/backend/tcop/backend_startup.c @@ -306,12 +306,12 @@ BackendInitialize(ClientSocket *client_sock, CAC_state cac) (errcode(ERRCODE_CANNOT_CONNECT_NOW), errmsg("the database system is starting up"))); break; - case CAC_NOTCONSISTENT: + case CAC_NOTCONSISTENT_OR_OVERFLOWED: if (EnableHotStandby) ereport(FATAL, (errcode(ERRCODE_CANNOT_CONNECT_NOW), errmsg("the database system is not yet accepting connections"), - errdetail("Consistent recovery state has not been yet reached."))); + errdetail("Consistent recovery state has not been yet reached, or snapshot is not ready for hot standby."))); else ereport(FATAL, (errcode(ERRCODE_CANNOT_CONNECT_NOW), diff --git a/src/include/tcop/backend_startup.h b/src/include/tcop/backend_startup.h index 578828c1ca..4a4b878e2d 100644 --- a/src/include/tcop/backend_startup.h +++ b/src/include/tcop/backend_startup.h @@ -36,7 +36,7 @@ typedef enum CAC_state CAC_STARTUP, CAC_SHUTDOWN, CAC_RECOVERY, - CAC_NOTCONSISTENT, + CAC_NOTCONSISTENT_OR_OVERFLOWED, CAC_TOOMANY, } CAC_state; base-commit: 19c6eb06c51f4da70e2ea0f1bdb64a0142e8e2aa -- 2.48.1