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. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
