From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > On Thu, May 18, 2017 at 11:30 PM, Robert Haas <robertmh...@gmail.com> wrote: > > Because why? > > Because it is critical to let the user know as well *why* an error happened. > Imagine that this feature is used with multiple nodes, all primaries. If > a DB admin busted the credentials in one of them then all the load would > be redirected on the other nodes, without knowing what is actually causing > the error. Then the node where the credentials have been changed would just > run idle, and the application would be unaware of that.
In that case, the DBA can know the authentication errors in the server log of the idle instance. I'm sorry to repeat myself, but libpq connection failover is the feature for HA. So I believe what to prioritize is HA. And the documentation looks somewhat misleading. I get the impression that libpq tries hosts until success regardless of failure reason: it aims for successful connection, not giving up early. Who can read this as "libpq gives up connection under some circumstances?" https://www.postgresql.org/docs/devel/static/libpq-connect.html -------------------------------------------------- It is possible to specify multiple host components, each with an optional port component, in a single URI. A URI of the form postgresql://host1:port1,host2:port2,host3:port3/ is equivalent to a connection string of the form host=host1,host2,host3 port=port1,port2,port3. Each host will be tried in turn until a connection is successfully established. ... If multiple host names are specified, each will be tried in turn in the order given. -------------------------------------------------- Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
