Re: Change log level for notifying hot standby is waiting non-overflowed snapshot

From: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Change log level for notifying hot standby is waiting non-overflowed snapshot
Date: 2025-03-12 12:57:31
Message-ID: fd0421ae13a11a559da74a5161882ff5@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

After an off-list discussion with Fujii-san, I'm now trying to modify
the following message that is output when a client attempts to connect
instead of changing the log level as the original proposal:

$ psql: error: connection to server at "localhost" (::1), port 5433
failed: FATAL: the database system is not yet accepting connections
DETAIL: Consistent recovery state has not been yet reached.

I have now 2 candidates to do this.

The 1st
one(v1-0001-Change-log-message-when-hot-standby-is-not-access.patch) is
a simple update to the existing log messages, explicitly mentioning that
snapshot overflow could be a possible cause.
The 2nd(v1-0001-Make-it-clear-when-hot-standby-is-inaccessible-du.patch)
one introduces new states for pmState and CAC_state (which manages
whether connections can be accepted) to represent waiting for a
non-overflowed snapshot.

The advantage of the 2nd one is that it makes it clear whether the
connection failure is due to not reaching a consistent recovery state or
a snapshot overflow. However, I haven't found other significant
benefits, and I feel it might be overkill.

Personally, I feel 1st patch may be sufficient, but I would appreciate
any feedback.

--
Atsushi Torikoshi
Seconded from NTT DATA GROUP CORPORATION to SRA OSS K.K.

Attachment Content-Type Size
v1-0001-Make-it-clear-when-hot-standby-is-inaccessible-du.patch text/x-diff 9.2 KB
v1-0001-Change-log-message-when-hot-standby-is-not-access.patch text/x-diff 3.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dagfinn Ilmari Mannsåker 2025-03-12 13:08:50 Re: Changing the state of data checksums in a running cluster
Previous Message David G. Johnston 2025-03-12 12:48:24 Re: Document NULL