On Sun, May 14, 2017 at 9:19 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Fri, May 12, 2017 at 10:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Michael Paquier <michael.paqu...@gmail.com> writes: >>> On Fri, May 12, 2017 at 1:28 PM, Tsunakawa, Takayuki >>> <tsunakawa.ta...@jp.fujitsu.com> wrote: >>>> Likewise, when the first host has already reached max_connections, libpq >>>> doesn't attempt the connection aginst later hosts. >> >>> It seems to me that the feature is behaving as wanted. Or in short >>> attempt to connect to the next host only if a connection cannot be >>> established. If there is a failure once the exchange with the server >>> has begun, just consider it as a hard failure. This is an important >>> property for authentication and SSL connection failures actually. >> >> I would not really expect that reconnection would retry after arbitrary >> failure cases. Should it retry for "wrong database name", for instance? >> It's not hard to imagine that leading to very confusing behavior. > > I guess not as well. That would be tricky for the user to have a > different behavior depending on the error returned by the server, > which is why the current code is doing things right IMO. Now, the > feature has been designed similarly to JDBC with its parametrization, > so it could be surprising for users to get a different failure > handling compared to that. Not saying that JDBC is doing it wrong, but > libpq does nothing wrong either.
I concur. -- 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
