Hello,
I'd consider [...]
Don't really see the value of either ...
What I see is [...].
I still don't see the value of it. [...].
Ok. I suggested to consider, you considered and rejected, fine with me!
--
Fabien.
Hello Garick,
I read the rational of the host/hostaddr artificial mapping. I cannot say
I'm thrilled with the result: I do not really see a setting where avoiding a
DNS query is required but which still needs a hostname for auth... If you
have GSSAPI or SSPI then you have an underlying
On Tue, Aug 14, 2018 at 03:18:32PM -0400, Garick Hamlin wrote:
> On Tue, Aug 14, 2018 at 12:24:32PM +0200, Fabien COELHO wrote:
> > I read the rational of the host/hostaddr artificial mapping. I cannot say
> > I'm thrilled with the result: I do not really see a setting where avoiding a
> > DNS
On Tue, Aug 14, 2018 at 12:24:32PM +0200, Fabien COELHO wrote:
>
> Hello Tom,
>
> >>As you noted in another message, a small doc update should be needed.
> >
> >Check. Proposed doc patch attached. (Only the last hunk is actually
> >specific to this patch, the rest is cleanup that I noticed
Fabien COELHO writes:
> The mention of possible reverse dns queries has been removed... but I do
> not think there was any before?
Yeah, that's why I took it out. If there ever were any reverse lookups in
libpq, we got rid of them AFAICS, so this statement in the docs seemed just
unnecessarily
Hello Tom,
As you noted in another message, a small doc update should be needed.
Check. Proposed doc patch attached. (Only the last hunk is actually
specific to this patch, the rest is cleanup that I noticed while looking
around for possibly-relevant text.)
Doc build is ok.
Some
Fabien COELHO writes:
> Patch compiles, global "make check" ok, although I'm unsure whether the
> feature is actually tested somewhere. I think not:-(
Yeah, it's hard to test this stuff without either opening up security
hazards or making unwarranted assumptions about the local network setup.
I
The Fatal error does not really say for which host/ip the password fail.
Yup, but that's not the province of this patch to improve. See
https://www.postgresql.org/message-id/25918.1533918...@sss.pgh.pa.us
for one that is trying to improve it.
Yep, I gathered that afterwards.
--
Fabien.
Fabien COELHO writes:
> In the same vein on a wrong password:
> sh> psql "host=no-such-host,local2.coelho.net,local3.coelho.net"
> Password for user fabien:
> psql: could not translate host name "no-such-host" to address: Name or
> service not known
> could not connect to server:
Fabien COELHO writes:
> About the behavior from psql point of view:
> * if dns works, error messages are only printed if all attempts failed:
> But nothing shows if one succeeds at some point. I understand that libpq
> is doing its job, but I'm wondering whether this is the best behavior.
On Thu, Aug 09, 2018 at 02:32:58PM -0400, Tom Lane wrote:
> Chapman Flack writes:
> > On 08/09/2018 11:05 AM, Tom Lane wrote:
> >> So I think what this code should do is (1) look up each hostname as it
> >> needs it, not all at once, and (2) proceed on to the next hostname
> >> if it gets a DNS
* when the password is required, there is no way to know for which host/ip it
is:
sh> psql "host=127.0.0.17,local2.coelho.net,local.coelho.net"
Password for user fabien:
In the same vein on a wrong password:
sh> psql "host=no-such-host,local2.coelho.net,local3.coelho.net"
Password for
Hello Tom,
[...]
So I think what this code should do is (1) look up each hostname as it
needs it, not all at once, and (2) proceed on to the next hostname
if it gets a DNS lookup failure, not fail the whole connection attempt
immediately. As attached.
A quick test, and very quick glance
Chapman Flack writes:
> On 08/09/2018 11:05 AM, Tom Lane wrote:
>> So I think what this code should do is (1) look up each hostname as it
>> needs it, not all at once, and (2) proceed on to the next hostname
>> if it gets a DNS lookup failure, not fail the whole connection attempt
>> immediately.
On 08/09/2018 11:05 AM, Tom Lane wrote:
> So I think what this code should do is (1) look up each hostname as it
> needs it, not all at once, and (2) proceed on to the next hostname
> if it gets a DNS lookup failure, not fail the whole connection attempt
> immediately. As attached.
Would it be
Alvaro Herrera writes:
> On 2018-Aug-09, Tom Lane wrote:
>> Whilst fooling with the patch for CVE-2018-10915, I got annoyed by
>> the fact that connectDBStart() does the DNS lookups for all supplied
>> hostnames at once, and fails if any of them are bad. It was reasonable
>> to do the lookup
On 2018-Aug-09, Tom Lane wrote:
> Whilst fooling with the patch for CVE-2018-10915, I got annoyed by
> the fact that connectDBStart() does the DNS lookups for all supplied
> hostnames at once, and fails if any of them are bad. It was reasonable
> to do the lookup there when we only allowed one
17 matches
Mail list logo
