From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: List of hostaddrs not supported |
Date: | 2017-06-09 10:36:07 |
Message-ID: | 841aa5cb-22f3-b332-7408-21f4a3b7770b@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/08/2017 06:18 PM, Robert Haas wrote:
> On Thu, Jun 8, 2017 at 10:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)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
Attachment | Content-Type | Size |
---|---|---|
0001-Allow-multiple-hostaddrs-to-go-with-multiple-hostnam.patch | invalid/octet-stream | 14.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2017-06-09 11:47:02 | Re: A bug in mapping attributes in ATExecAttachPartition() |
Previous Message | Mithun Cy | 2017-06-09 10:22:20 | Re: List of hostaddrs not supported |