Hello Robert, Tom,
Thank you for being kind enough to explain. I think I could understand your
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Who is right is a judgement call, but I don't think it's self-evident that
> users want to ignore anything and everything that might have gone wrong
> with the connection to the first server, rather than only those things which
> resemble a down server. It seems quite possible to me that if we had defined
> it as you are proposing, somebody would now be arguing for a behavior change
> in the other direction.
Judgment call... so, I understood that it's a matter of choosing between
helping to detect configuration errors early or service continuity. Hmm, I'd
like to know how other databases treat this, but I couldn't find useful
information after some Google search. I wonder whether I sould ask PgJDBC
people if they know something, because they chose service continuity.
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> The bigger picture here is that we only want to fail past transient errors,
> not configuration errors. I'm willing to err in favor of regarding doubtful
> cases as transient, but most server login rejections aren't for transient
I got "doubtful cases" as ones such as specifying non-existent host or an
unused port number. In that case, the configuration error can't be
distinguished from the server failure.
What do you think of the following cases? Don't you want to connect to other
* 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
These are equivalent to server failure. I believe we should prioritize
rescuing errors during operation over detecting configuration errors.
> Of course, the user would have to try connections to both foo and bar to
> be sure that they're both configured correctly. But he might try
> "host=foo,bar" and "host=bar,foo" and figure he was OK, not noticing that
> both connections had silently been made to bar.
In that case, I think he would specify "host=foo" and "host=bar" in turn,
because he would be worried about where he's connected if he specified multiple
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: