Re: libpq should append auth failures, not overwrite - Mailing list pgsql-hackers

On Wed, Aug 15, 2018 at 12:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> TBH I find your example to be the exact opposite of convincing.
> You've cherry-picked a case where the current behavior tells you
> what you need to know and not anything you don't, but very small
> variations on the case make that not hold anymore.  Remember the
> complaint we started with, which was that if you get a bad-password
> error it's not apparent which host gave that response.  If, in
> fact, the hosts you've listed don't all use the same password,
> you could be tearing your hair out for quite awhile before you
> figure out what's going wrong.

That seems like a pretty unlikely use case, though.  It seems to me
that the virtue of the feature is in letting you connect to one of a
number of hosts that are basically all equivalent.  If they're not all
equivalent, how come you're OK with connecting to any one of them?
It's of course not impossible for somebody to have databases with
equivalent contents but different authentication, but that sounds like
some kind of confusing fringe thing to me.  My guess -- and I think
this is what underlay the original coding, though maybe I didn't get
all the details right -- is that if your connection fails to reach any
server, you want to know the details as to why that failed for each
server in the list, but that if your connection fails for some reason
other than not being able to reach the server at all, like a missing
role name or password, you just want to know about that, and you don't
really care about the servers to which you failed to connect
altogether.  Saying host=a,b,c basically means exactly that: I don't
really care about failure to connect to a or even a and b; that's not
an error condition.  Of course if I can't connect to any of them --
that's still got to be an error.

> In any case, I'm a little bit confused as to why someone who'd
> listed multiple hosts would be surprised to see that the connection
> had in fact fallen back to not-the-first host.

In a perfect world where users never misinterpret error messages, they
wouldn't, but that is not a world I have the privilege of inhabiting.
Focusing the error on the thing that is probably what the user needs
to fix is a very sensible decision, I think.  We could print out a
full stack backtrace, a memory context dump, and a node tree display
of the plan every time a query errors out, but most of the time, that
would be a truly excessive amount of information that would distract
from, say, the fact that you divided by zero, or whatever.  Brevity
has value.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company