On Sun, Jun 10, 2012 at 8:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
