Robert Haas <robertmh...@gmail.com> writes: > On Sun, May 14, 2017 at 9:50 PM, Tsunakawa, Takayuki > <tsunakawa.ta...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers