Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, May 14, 2017 at 9:50 PM, Tsunakawa, Takayuki
> <tsunakawa.takay@jp.fujitsu.com> wrote:
>> By the way, could you elaborate what problem could occur if my solution is applied? (it doesn't seem easy for me to
imagine...)
> Sure. Imagine that the user thinks that 'foo' and 'bar' are the
> relevant database servers for some service and writes 'dbname=quux
> host=foo,bar' as a connection string. However, actually the user has
> made a mistake and 'foo' is supporting some other service entirely; it
> has no database 'quux'; the database servers which have database
> 'quux' are in fact 'bar' and 'baz'.
Even more simply, suppose that your userid is known to host bar but the
DBA has forgotten to create it on foo. This is surely a configuration
error that ought to be rectified, not just failed past, or else you don't
have any of the redundancy you think you do.
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.
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.
There might be specific post-connection errors that we should consider
retrying; "too many connections" is an obvious case.
regards, tom lane