database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Improve error message when standby does accept connections.

Browse Source 
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
This commit is contained in:
Fujii Masao
2025-04-02 15:13:01 +09:00
parent 121d774cae
commit b53b88109f
6 changed files with 40 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
doc/src/sgml/high-availability.sgml
View File

@ -1535,7 +1535,8 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
<para>
When the <xref linkend="guc-hot-standby"/> 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
brought the system to a consistent state and be ready for hot standby.
All such connections are
strictly read-only; not even temporary tables may be written.
</para>
@ -1974,9 +1975,12 @@ LOG: database system is ready to accept read-only connections
Consistency information is recorded once per checkpoint on the primary.
It is not possible to enable hot standby when reading WAL
written during a period when <varname>wal_level</varname> was not set to
<literal>replica</literal> or <literal>logical</literal> on the primary. Reaching
a consistent state can also be delayed in the presence of both of these
conditions:
<literal>replica</literal> or <literal>logical</literal> on the primary.
Even after reaching a consistent state, the recovery snapshot may not
be ready for hot standby if both of the following conditions are met,
delaying accepting read-only connections. To enable hot standby,
long-lived write transactions with more than 64 subtransactions
need to be closed on the primary.
<itemizedlist>
<listitem>