Re: Ability to listen on two unix sockets - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Ability to listen on two unix sockets
Date
Msg-id 20620.1339364113@sss.pgh.pa.us
Whole thread Raw
In response to Re: Ability to listen on two unix sockets  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Ability to listen on two unix sockets  (Robert Haas <robertmhaas@gmail.com>)
Re: Ability to listen on two unix sockets  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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:
>>> 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'm uncomfortable with the potential for ambiguity there.  I think we'd
be much better off having two lists, one for TCP addresses and one for
Unix socket directories.

I'm unconvinced that allowing multiple port numbers is worth the
amount of confusion it will cause.  In particular, we've traditionally
used "the port number" as part of the key for resources such as shared
memory.  I think we'd want the number used for that purpose to be what
is written into the lock file ... but then what if the postmaster is not
actually listening on *any* actual socket with that number?  pg_ctl will
not be happy.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)
Next
From: Tom Lane
Date:
Subject: Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)