Re: Ability to listen on two unix sockets

On Sun, Jun 10, 2012 at 5:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Jun 10, 2012 at 5:06 PM, Peter Eisentraut <peter_e(at)gmx(dot)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 suggested it mostly because we already use that convention in libpq:
leading slash = pathname.

> 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.

Well, that's why I shied away from the syntax Peter is proposing. I
think if we leave the semantics of listen_addresses and port alone,
and just add a new GUC for extra places to listen, there's no problem.
If you look at the patch I posted upthread, you'll see that I set
things up so that we'll still fail if the primary port can't be
listened on; once we've established that we can listen there, we'll
try to set up the other sockets as well. I think that's a pretty sane
way to allow this (which a number of people, not only me, seem to
support) without creating surprising semantics.

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