Skip site navigation (1) Skip section navigation (2)

Re: Ability to listen on two unix sockets

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Florian Pflug <fgp(at)phlo(dot)org>, Honza Horak <hhorak(at)redhat(dot)com>
Subject: Re: Ability to listen on two unix sockets
Date: 2012-06-06 14:50:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wednesday, June 06, 2012 04:38:42 PM Tom Lane wrote:
> Florian Pflug <fgp(at)phlo(dot)org> writes:

> > If we're going to have this at all, we should go all the way and
> > support an arbitrary number of sockets.
> Well, that's what I wanted to discuss before Honza starts coding.
> It's not obvious that there are any use-cases for more than two.
> It's also not clear whether there is any value in supporting run-time
> rather than build-time configuration of the socket locations.  The
> Fedora use-case has no need of that, but if people can point to other
> cases where it would be sensible, we can write the patch that way.
I had the need to make pg available from multiple chroots via unix sockets. 
The same might come up more frequently with the availability of filesystem 

> You might think we should design this exactly like the TCP-socket
> multiple-listen-addresses case, ie just have a config variable
> containing a list of directory names.  The sticking point there is
> that the directories aren't really interchangeable.  In particular,
> there is still going to be one directory that is the one hard-wired
> into libpq.
I wonder if the whole issue doesn't require libpq to also try multiple 
hardcoded socket locations.


 Andres Freund	         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2012-06-06 14:50:37
Subject: Re: Ability to listen on two unix sockets
Previous:From: Tom LaneDate: 2012-06-06 14:38:42
Subject: Re: Ability to listen on two unix sockets

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group