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
