On 06/10/2012 03:41 PM, Robert Haas wrote:
On Sun, Jun 10, 2012 at 8:36 AM, Tom Lane<t...@sss.pgh.pa.us> wrote:
Peter Eisentraut<pete...@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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers