Hello Robert, Tom,

Thank you for being kind enough to explain.  I think I could understand your 

From: pgsql-hackers-ow...@postgresql.org
> [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
> causes.

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 

Takayuki Tsunakawa

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to