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

Re: Ability to listen on two unix sockets

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Honza Horak <hhorak(at)redhat(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Ability to listen on two unix sockets
Date: 2012-06-06 14:16:00
Message-ID: 5B295BB4-485D-4718-8011-DA3290C84AB6@phlo.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Jun6, 2012, at 15:50 , Honza Horak wrote:
> before I ask the main question, just a little background for one issue we're currently having in Fedora 17:
> 
> PrivateTmp is a systemd's feature, which allows to have private /tmp directory for services, which in turn means that such services aren't able to access systems's /tmp directory. It's been enabled by some services already, including Apache, while PostgreSQL uses system's /tmp directory, where its unix socket is located. Naturally, it resulted in a state, where Apache or other services with PrivateTmp enabled are not able to communicate with PostgreSQL using the socket.

Couldn't you simply tell postgres to put it's socket in, say, /var/run, and create a symlink to that socket in the global /tmp directory?

> Since we don't want just to move socket for compatibility reasons, I'm going to prepare a draft patch to allow PostgreSQL to use a second unix socket at a time. A question I'd like to ask now is: Do we need a new configuration variable for this or it's enough to have the location hard-coded? What are your opinions?

If we're going to have this at all, we should go all the way and support an arbitrary number of sockets. But then, is there any advantage in providing this feature natively compare to simply creating symlinks?

best regards,
Florian Pflug


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-06-06 14:38:42
Subject: Re: Ability to listen on two unix sockets
Previous:From: Tom LaneDate: 2012-06-06 14:11:42
Subject: Re: ExecStoreTuple going into infinite loop

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