On Wed, May 17, 2017 at 3:06 AM, Tsunakawa, Takayuki <tsunakawa.ta...@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 because it takes many seconds to write > the stats file (as you remember, Tom-san experienced 57 seconds to write the > stats file 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 detecting configuration 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
