Re: libpq should append auth failures, not overwrite

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: libpq should append auth failures, not overwrite
Date: 2018-08-15 16:05:55
Message-ID: 10646.1534349155@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Aug 15, 2018 at 11:53 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> As soon as you have multiple target hosts, though, the current code's
>> behavior is inadequate IMO.

> I'm not entirely convinced; see the example I posted before.

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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2018-08-15 16:07:40 Re: C99 compliance for src/port/snprintf.c
Previous Message Robert Haas 2018-08-15 16:04:53 Re: Facility for detecting insecure object naming