On Wed, May 17, 2017 at 3:06 AM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> What do you think of the following cases? Don't you want to connect to other servers?
>
> * The DBA shuts down the database. The server takes a long time to do checkpointing. During the shutdown
checkpoint,libpq tries to connect to the server and receive an error "the database system is shutting down."
>
> * The former primary failed and now is trying to start as a standby, catching up by applying WAL. During the
recovery,libpq tries to connect to the server and receive an error "the database system is performing recovery."
>
> * The database server crashed due to a bug. Unfortunately, the server takes unexpectedly long time to shut down
becauseit takes many seconds to write the stats file (as you remember, Tom-san experienced 57 seconds to write the
statsfile during regression tests.) During the stats file write, libpq tries to connect to the server and receive an
error"the database system is shutting down."
>
> These are equivalent to server failure. I believe we should prioritize rescuing errors during operation over
detectingconfiguration errors.
Yeah, you have a point. I'm willing to admit that we may have defined
the behavior of the feature incorrectly, provided that you're willing
to admit that you're proposing a definition change, not just a bug
fix.
Anybody else want to weigh in with an opinion here?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company