Re: [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur
Date: 2017-05-19 00:11:13
Message-ID: CAB7nPqTo_vi-66rDmzUT4dCcAjVP7K-XsdPxUTuA0VJXFmbX3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 18, 2017 at 11:30 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, May 18, 2017 at 7:06 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> FWIW, I am of the opinion to not have an implementation based on any
>> SQLSTATE codes, as well as not doing something similar to JDBC.
>> Keeping things simple is one reason, a second is that the approach
>> taken by libpq is correct at its root.
>
> 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.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-05-19 00:30:17 fix for table syncing with different column order
Previous Message Michael Paquier 2017-05-19 00:07:46 Re: [Proposal] Allow users to specify multiple tables in VACUUM commands