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

From Robert Haas
Subject Re: Ability to listen on two unix sockets
Date
Msg-id CA+Tgmob080VHtP0Sg1-RzELX793go_9VP+mr8mCs2w5ktkXfEA@mail.gmail.com
Whole thread Raw
In response to Re: Ability to listen on two unix sockets  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Jun 10, 2012 at 5:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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 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'llsee 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)
Next
From: Jeff Frost
Date:
Subject: Re: Backends stalled in 'startup' state: index corruption