Re: Change log level for notifying hot standby is waiting non-overflowed snapshot - Mailing list pgsql-hackers

From torikoshia
Subject Re: Change log level for notifying hot standby is waiting non-overflowed snapshot
Date
Msg-id fd0421ae13a11a559da74a5161882ff5@oss.nttdata.com
Whole thread Raw
In response to Re: Change log level for notifying hot standby is waiting non-overflowed snapshot  (torikoshia <torikoshia@oss.nttdata.com>)
Responses Re: Change log level for notifying hot standby is waiting non-overflowed snapshot
List 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

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Document NULL
Next
From: Dagfinn Ilmari Mannsåker
Date:
Subject: Re: Changing the state of data checksums in a running cluster