Re: Ability to listen on two unix sockets

On 06/10/2012 03:41 PM, Robert Haas wrote:
> On Sun, Jun 10, 2012 at 8:36 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Peter Eisentraut<peter_e(at)gmx(dot)net> writes:
>>> On lör, 2012-06-09 at 18:26 -0400, Tom Lane wrote:
>>>> That's not actually quite the same thing as what I suggest above.
>>>> Currently, unix_socket_directory *overrides* the compiled-in choice.
>>>> I'm suggesting that it would be better to invent a list that is *added
>>>> to* the compiled-in choice. If we think it would be best to still be
>>>> able to override that, then I'd vote for keeping unix_socket_directory
>>>> as is, and then adding a list named something like
>>>> "secondary_socket_directories". But if we just turn
>>>> unix_socket_directory into a list, I think the lack of separation
>>>> between primary and secondary directories will be confusing.
>>
>>> By that logic, any list-valued parameter should be split into a primary
>>> and secondary setting.
>>
>> Well, no: the key point here is that there will be one directory that is
>> special because it's the one baked into libpq. I agree that for the
>> purposes of the backend in isolation, we might as well just have a list.
>> What's less clear is whether, when considering the backend+client
>> ecosystem as a whole, the special status of the configure-time socket
>> directory ought to be reflected in the way we set up the GUCs. I have
>> to admit that I'm not totally sold on either approach.
>
> I think we should consider this in the context of allowing both
> additional UNIX sockets and additional TCP ports. In the case of TCP
> ports, it's clearly no good to turn "port" into a list, because one
> port number has to be primary, since it goes into the PID file and
> also affects the naming of any UNIX sockets created. If we add
> secondary_socket_dirs, I think we will also need secondary_ports. One
> idea might be to have one new GUC that serves both purposes:
>
> additional_sockets = '12345, /foo'
>
> I'm sure there are other ways to skin the cat as well.

Going through the thread, I'd like to sum it up choosing approach with
less potential issues and would like to find a consensus if possible.

It seems unix_socket_directory could be turned into list and probably
renamed to unix_socket_directories, since it would be confusing if a
list value is in singular. On the other hand, we probably don't want to
specify listening ports together with additional unix sockets in one
configuration option, so it seems better to add a new configuration
option to distinguish the primary listening port from additional ports.

Regards,
Honza