Re: Ability to listen on two unix sockets

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, Honza Horak <hhorak(at)redhat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Ability to listen on two unix sockets
Date: 2012-06-10 21:35:13
Message-ID: 20620.1339364113@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 sn, 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-06-10 21:37:50 Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)
Previous Message Robert Haas 2012-06-10 21:27:33 Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)