Re: libpq should not look up all host addresses at once - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: libpq should not look up all host addresses at once
Date
Msg-id alpine.DEB.2.21.1808132356130.2727@lancre
Whole thread Raw
In response to Re: libpq should not look up all host addresses at once  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: libpq should not look up all host addresses at once
Re: libpq should not look up all host addresses at once
List pgsql-hackers
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 comments that you may not find all useful, please accept my apology, 
it just really shows that I read your prose in some detail:-)

The mention of possible reverse dns queries has been removed... but I do 
not think there was any before? There could be if only hostaddr is 
provided but a hostname is required by some auth, but it does not seem to 
be the case according to the documentation.

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 network, in which a 
dns query should be fine.

Moreover the feature implementation is misleading as hostaddr changes the 
behavior of host when both are provided. Also, "hosts" accepts ips anyway 
(although is not documented).

STM that we should have had only "host" for specifying the target (name, 
ip, path), and if really necessary an ugly "authname" directive to provide 
names on the side. I know, too late.

I think that in the string format host=foo:5433,bla:5432 could be 
accepted as it is in the URL format.

Some of the changes are not directly related to the multi host feature, 
and should/could be backpatched further?

>> I'd consider wrapping some of the logic. I'd check the port first, then
>> move the host resolution stuff into a function.
>
> Don't really see the value of either ...

What I see is that the host logic is rather lengthy and specific (it 
depends on the connection type -- name, ip, socket including a so nice 
#ifdef), distinct from the port stuff which is dealt with quite quickcly.

By separating the port & host and putting the lengthy stuff in a function 
the scope of the for loop on potential connections would be easier to read 
and understand, and would not require to see CHT_ cases to understand what 
is being done for managing "host" variants, which is a mere detail.

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Jarosław Torbicki
Date:
Subject: Uncaught PHP ExceptionDoctrine\DBAL\Exception\UniqueConstraintViolationException: "An exceptionoccurred while executing 'UPDATE
Next
From: Geoff Winkless
Date:
Subject: Re: NetBSD vs libxml2