On Sun, Jun 10, 2012 at 5:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, Jun 10, 2012 at 5:06 PM, Peter Eisentraut <pete...@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'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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
