Re: Ability to listen on two unix sockets

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On lr, 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.

regards, tom lane