Re: Ability to listen on two unix sockets

On Sun, Jun 10, 2012 at 5:06 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On sön, 2012-06-10 at 09:41 -0400, Robert Haas wrote:
>> 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
>
> Not necessarily.  The port number in the PID file is only used for
> pg_ctl to contact the server, and for that it only needs some port, not
> the primary one.  Also, we write the first listen_address into the PID
> file for the same reason.  So if you think there should be a primary
> port, then there should also be a primary listen_addresses.

Fair enough, as far as this part goes, but...

>> and also affects the naming of any UNIX sockets created.
>
> Why would that matter?  If you configure M ports and N Unix socket
> locations, you get M*N actual sockets created.

...I *seriously* doubt that this is the behavior anyone wants.
Creating M sockets per directory seems patently silly.

>> 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 was getting around to that, although I don't follow the specific
> syntax you have chosen here.

I was thinking that each element could be of the form /path or port.
But I guess it should really be /path or host:port.

> I would like something where you set host and port together, so you can
> listen on port 5432 on localhost, and port 5433 on *, for example.  So
> maybe
>
> listen_addresses = localhost:5432,*:5433
>
> Web servers usually allow that sort of thing, but if you dig deep there,
> the configuration settings and their interactions can get pretty
> complicated.  For example, you can usually set a default port and then
> override it in the listen_addresses equivalent.

That seems like the obvious syntax, but I'm fuzzy on the details.  We
could let 'port' continue to mean the default port, and then
listen_addresses can contain either unadorned addresses (in which case
we bind to that address using the default port) or address:port
designators (in which case we bind to the given address and port).
But then support port = 1234 and listen_addresses = '5.5.5.5:6789'.
Presumably the UNIX socket is still /tmp/.s.PGSQL.1234, but then what
ends up in the lock file?  PostmasterMain's current algorithm for
figuring that out would write 5.5.5.5 for the host and 1234 for the
port, which seems like nonsense.  Such confusion is why I thought we
might fall back on listing all the additional listen locations in a
new, separate GUC.  But perhaps there is a way to make it work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company