Re: [HACKERS] List of hostaddrs not supported

On 06/08/2017 06:18 PM, Robert Haas wrote:
> On Thu, Jun 8, 2017 at 10:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> It doesn't seem like a problem to me if somebody else wants to extend
>>> it to hostaddr, though.  Whether that change belongs in v10 or v11 is
>>> debatable.  I would object to adding this as an open item with me as
>>> the owner because doesn't seem to me to be a must-fix issue, but I
>>> don't mind someone else doing the work.
>>
>> If you want to define multiple-hostaddrs as a future feature, that
>> seems fine, but I think Heikki is describing actual bugs.  The minimum
>> that I think needs to be done for v10 is to make libpq reject a hostaddr
>> string with the wrong number of entries (either different from the
>> host list, or different from 1).
>
> Whatever you put in the hostaddr field - or any field other than host
> and port - is one entry.  There is no notion of a list of entries in
> any other field, and no attempt to split any other field on a comma or
> any other symbol.  The fact that ::1,::1 looks to you like two entries
> rather than a single malformed entry is just a misunderstanding on
> your part, just like you'd be wrong if you thought that
> password=foo,bar is a list of passwords rather than a password
> containing a comma.
>
> I think the argument is about whether I made the right decision when I
> scoped the feature, not about whether there's a defect in the
> implementation.

Right. I think it's a usability fail as it is; it certainly fooled me. 
We could make the error messages and documentation more clear. But even 
better to allow multiple host addresses, so that it works as you'd expect.

I understand the slippery-slope argument that you might also want to 
have different usernames etc. for different hosts, but it's confusing 
that specifying a hostaddr changes the way the host-argument is 
interpreted. In the worst case, if we let that stand, someone might 
actually start to depend on that behavior. The other options don't have 
that issue. And hostaddr is much more closely tied to specifying the 
target to connect to, like host and port are.

I propose the attached patch, to allow a comma-separated list of 
hostaddr's. It includes some refactoring of the code to parse 
comma-separated lists, as it was getting a bit repetitive. It also fixes 
a couple of minor issues in error messages, see commit message.

The patch doesn't include docs changes yet. I think we should add a new 
sub-section, at the same level as the "33.1.1.1. Keyword/Value 
Connection Strings" and "33.1.1.2. Connection URIs" sub-sections, to 
explain some of the details we've discussed here. Something like:

---
33.1.1.3 Specifying Multiple Hosts

It is possible to specify multiple hosts to connect to, so that they are 
tried in the order given. In the Keyword/Value syntax, the host, 
hostaddr, and port options accept a comma-separated list of values. The 
same number of elements should be given in each option, such that e.g. 
the first hostaddr corresponds to the first host name, the second 
hostaddr corresponds to the second host name, and so forth. As an 
exception, if only one port is specified, it applies to all the hosts.

In the connection URI syntax, you can list multiple host:port pairs 
separated by commas, in the host component of the URI.

A single hostname can also translate to multiple network addresses. A 
common example of this is that a host can have both an IPv4 and an IPv6 
address.

When multiple hosts are specified, or when a single hostname is 
translated to multiple addresses,  all the hosts and addresses will be 
tried in order, until one succeeds. If none of the hosts can be reached, 
the connection fails. If a connection is established successfully, but 
authentication fails, the remaining hosts in the list are not tried.

If a password file is used, you can have different passwords for 
different hosts. All the other connection options are the same for every 
host, it is not possible to e.g. specify a different username for 
different hosts.
---

- Heikki


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers