Ability to listen on two unix sockets
Hi,
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.
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?
Regards,
Honza
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
Florian Pflug <fgp@phlo.org> writes:
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?
FYI, this proposal emerged out of a discussion between Honza and
myself. "Use a symlink" was my first idea too, but on reflection
it seems like it will take less new code to support two sockets.
We already support multiple TCP sockets, so multiple Unix sockets
shouldn't be that much extra trouble.
The reasons a symlink doesn't seem attractive are:
1. The code to create/delete it has to be in the postmaster. If we
tried to make the Fedora-specific startup script manage it, we would
first have to teach that script how to know which port number the
postmaster will select, which means parsing config files. Ugh.
2. What if two postmasters try to create a symlink in the same place?
Or we're just trying to decide if the previous creator crashed without
removing it? So we need a lockfile beside it. So at this point we are
building a whole bunch of new infrastructure to create symlinks, whereas
we can probably just call the same subroutine twice if we go with the
two-socket design.
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.
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. So whereas multiple TCP sockets really are pretty much
interchangeable, I think in the Unix-socket case we are going to have
to think of it as being a primary socket and one or more alternate
sockets. Is there a reason to have more than one alternate, and if
so what is the use-case?
(BTW, we would probably just adopt the Debian solution if we were
sure there were no non-libpq clients out there; but we aren't.)
regards, tom lane
On Wednesday, June 06, 2012 04:38:42 PM Tom Lane wrote:
Florian Pflug <fgp@phlo.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
namespaces...
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
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Excerpts from Tom Lane's message of mié jun 06 10:38:42 -0400 2012:
Florian Pflug <fgp@phlo.org> writes:
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?
FYI, this proposal emerged out of a discussion between Honza and
myself. "Use a symlink" was my first idea too, but on reflection
it seems like it will take less new code to support two sockets.
We already support multiple TCP sockets, so multiple Unix sockets
shouldn't be that much extra trouble.The reasons a symlink doesn't seem attractive are:
1. The code to create/delete it has to be in the postmaster. If we
tried to make the Fedora-specific startup script manage it, we would
first have to teach that script how to know which port number the
postmaster will select, which means parsing config files. Ugh.
Well, you could use
postmaster -C port
The other reason seems compelling enough, though ... particularly,
handling a lockfile sounds messy; if it's a symlink and it's created by
the script, then it would need a separate lockfile, and filling its data
wouldn't be exactly trivial.
(BTW, we would probably just adopt the Debian solution if we were
sure there were no non-libpq clients out there; but we aren't.)
Maybe this is a good time to make the /var/run socket location (Debian's
choice) the primary one, and /tmp be the alternate.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 06/06/2012 04:50 PM, Andres Freund wrote:
On Wednesday, June 06, 2012 04:38:42 PM Tom Lane wrote:
Florian Pflug<fgp@phlo.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
namespaces...
It seems you were not alone with such need:
http://archives.postgresql.org/pgsql-novice/2006-09/msg00172.php
Honza
Alvaro Herrera <alvherre@commandprompt.com> writes:
Excerpts from Tom Lane's message of mié jun 06 10:38:42 -0400 2012:
(BTW, we would probably just adopt the Debian solution if we were
sure there were no non-libpq clients out there; but we aren't.)
Maybe this is a good time to make the /var/run socket location (Debian's
choice) the primary one, and /tmp be the alternate.
I'm not really in favor of making /var/run be the out-of-the-box
default, because it would discriminate against personal/testing
installations (ie, you couldn't set it up without root privileges).
It's a reasonable choice for distro-provided packages, but not so
much for one-off builds --- think about the buildfarm if nothing else.
Having said that, if we made it easier to configure things that way than
by patching the source, I bet Martin Pitt isn't going to object.
regards, tom lane
Honza Horak <hhorak@redhat.com> writes:
On 06/06/2012 04:50 PM, Andres Freund wrote:
On Wednesday, June 06, 2012 04:38:42 PM Tom Lane wrote:
Florian Pflug<fgp@phlo.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
namespaces...
It seems you were not alone with such need:
http://archives.postgresql.org/pgsql-novice/2006-09/msg00172.php
I had forgotten that conversation, but it does seem like there is
interest in this type of configuration. Can anybody confirm that
dropping a socket into a chroot or jail would actually work, ie
make it possible to connect from inside the chroot to a postmaster
running outside? If that's real and not just wishful thinking,
it seems like enough of an argument to justify supporting N sockets.
regards, tom lane
On Wed, Jun 06, 2012 at 11:32:45AM -0400, Tom Lane wrote:
I had forgotten that conversation, but it does seem like there is
interest in this type of configuration. Can anybody confirm that
dropping a socket into a chroot or jail would actually work, ie
make it possible to connect from inside the chroot to a postmaster
running outside? If that's real and not just wishful thinking,
it seems like enough of an argument to justify supporting N sockets.
We need to deal with exactly this sort of issue with schroot, where
we may want to provide programs in the chroot with access to
facilities outside the chroot. We generally just bind mount in the
minimal set of stuff needed. This might mean binding just the socket,
or it could be /var/run/postgresql. We do this for the X11 socket
for our desktop configuration profile to permit X11 programs to run
in a chroot, though we currently bind mount all of /tmp rather than
just the socket, since we want that as well in any case.
(http://people.debian.org/~rleigh/schroot.pdf)
While not exactly what was proposed (multiple sockets), this allows
one to re-use a single socket without the daemon requiring any
special support for it.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
On Wed, Jun 6, 2012 at 10:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.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. So whereas multiple TCP sockets really are pretty much
interchangeable, I think in the Unix-socket case we are going to have
to think of it as being a primary socket and one or more alternate
sockets. Is there a reason to have more than one alternate, and if
so what is the use-case?(BTW, we would probably just adopt the Debian solution if we were
sure there were no non-libpq clients out there; but we aren't.)
I recently had an urge to make it possible for the postmaster to
listen on multiple ports and even went so far as to code up a patch to
allow that. It still applies, with offsets, so I'll attach it here.
So I guess I'm +1 on the idea of allowing N UNIX sockets rather than
limiting it to N=2, and really I'd like to do one better and allow
listening on multiple TCP ports as well. Since the PID file contains
the port number, multiple TCP sockets stop being interchangeable as
soon as you allow multiple ports, but that's not very difficult to
handle. Now, you might ask whether this has any real-world value, and
obviously I'm going to say yes or I wouldn't be proposing it. The
reason for wanting multiple UNIX sockets is because those sockets
might be in different places that are not all equally accessible to
everyone, because of things like chroot. But of course the same thing
is possible in the network space using iptables and similar tools.
For example, you might want to have users connect to application A
using port 5432, and to application B using port 15432. Now you can
use network monitoring tools to see how much data each application is
sending and receiving, without needing deep packet inspection. You
can firewall those ports differently to provide access to different
groups of users. And you can even decide, if the database gets
overloaded, to cut off access to one of those ports, so that the
application causing the problem becomes inaccessible but the rest of
the database ceases being overloaded and you can still operate. Of
course, you could also do that by changing pg_hba.conf, but for some
people it might be more convenient (or feel more bullet-proof) to do
it using network management tools. There are probably other use
cases, as well.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
additional-sockets.patchapplication/octet-stream; name=additional-sockets.patchDownload+100-0
On Wed, Jun 6, 2012 at 1:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Jun 6, 2012 at 10:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.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. So whereas multiple TCP sockets really are pretty much
interchangeable, I think in the Unix-socket case we are going to have
to think of it as being a primary socket and one or more alternate
sockets. Is there a reason to have more than one alternate, and if
so what is the use-case?(BTW, we would probably just adopt the Debian solution if we were
sure there were no non-libpq clients out there; but we aren't.)I recently had an urge to make it possible for the postmaster to
listen on multiple ports and even went so far as to code up a patch to
allow that. It still applies, with offsets, so I'll attach it here.
So I guess I'm +1 on the idea of allowing N UNIX sockets rather than
limiting it to N=2, and really I'd like to do one better and allow
listening on multiple TCP ports as well. Since the PID file contains
the port number, multiple TCP sockets stop being interchangeable as
soon as you allow multiple ports, but that's not very difficult to
handle. Now, you might ask whether this has any real-world value, and
obviously I'm going to say yes or I wouldn't be proposing it. The
reason for wanting multiple UNIX sockets is because those sockets
might be in different places that are not all equally accessible to
everyone, because of things like chroot. But of course the same thing
is possible in the network space using iptables and similar tools.
For example, you might want to have users connect to application A
using port 5432, and to application B using port 15432. Now you can
use network monitoring tools to see how much data each application is
sending and receiving, without needing deep packet inspection. You
can firewall those ports differently to provide access to different
groups of users. And you can even decide, if the database gets
overloaded, to cut off access to one of those ports, so that the
application causing the problem becomes inaccessible but the rest of
the database ceases being overloaded and you can still operate. Of
course, you could also do that by changing pg_hba.conf, but for some
people it might be more convenient (or feel more bullet-proof) to do
it using network management tools. There are probably other use
cases, as well.
+1 for multiple TCP port numbers.
A few days ago I started working on enabling Postgres to communicate using
WebSockets protocol (acting as a wrapper around FE/BE), and I found it
difficult (not impossible) to use the same port for communicating FE/BE
protocol and for https+WebSockets too. It would have been a lot simpler if
I could say that WebSockets is enabled on 5431 and FE/BE on 5432.
Regards,
--
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
On 06/06/2012 04:50 PM, Andres Freund wrote:
On Wednesday, June 06, 2012 04:38:42 PM Tom Lane wrote:
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.
I guess so. Let's say we add additional socket support and some server
uses one e.g. at /var/run/postgresql. Then a client can either (1)
specify the same path explicitly and then we don't need to specify any
additional sockets on the client side or (2) stick to the default path,
which is hard-coded, currently to /tmp.
Going back to the original problem (inaccessible /tmp directory), it is
the case (2) -- a client uses the default path. So any additional
client-side socket option won't probably help here, but we would
probably need a second hard-coded path e.g. at /var/run/postgresql.
Regards,
Honza
Honza Horak <hhorak@redhat.com> writes:
On 06/06/2012 04:50 PM, Andres Freund wrote:
I wonder if the whole issue doesn't require libpq to also try multiple
hardcoded socket locations.
I guess so.
I don't really want to go there. Some use cases have been shown in
this thread for having a server listen in multiple places, but that does
not translate to saying that clients need to support automatically
looking in multiple places. I think that mainly introduces questions we
could do without, like which server did you actually end up contacting.
regards, tom lane
On Thursday, June 07, 2012 05:55:11 PM Tom Lane wrote:
Honza Horak <hhorak@redhat.com> writes:
On 06/06/2012 04:50 PM, Andres Freund wrote:
I wonder if the whole issue doesn't require libpq to also try multiple
hardcoded socket locations.I guess so.
I don't really want to go there. Some use cases have been shown in
this thread for having a server listen in multiple places, but that does
not translate to saying that clients need to support automatically
looking in multiple places. I think that mainly introduces questions we
could do without, like which server did you actually end up contacting.
It would be really nice to have a development psql connect to a distro
installed psql and vice versa without having to specify -h /var/run/psql and -
h /tmp all the time...
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Jun 7, 2012 at 11:57 AM, Andres Freund <andres@2ndquadrant.com> wrote:
On Thursday, June 07, 2012 05:55:11 PM Tom Lane wrote:
Honza Horak <hhorak@redhat.com> writes:
On 06/06/2012 04:50 PM, Andres Freund wrote:
I wonder if the whole issue doesn't require libpq to also try multiple
hardcoded socket locations.I guess so.
I don't really want to go there. Some use cases have been shown in
this thread for having a server listen in multiple places, but that does
not translate to saying that clients need to support automatically
looking in multiple places. I think that mainly introduces questions we
could do without, like which server did you actually end up contacting.It would be really nice to have a development psql connect to a distro
installed psql and vice versa without having to specify -h /var/run/psql and -
h /tmp all the time...
This is true, but you have this problem already. It might be worth
fixing, but it seems like a separate issue from the topic of this
thread, which is where the server listens.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Andres Freund <andres@2ndquadrant.com> writes:
On Thursday, June 07, 2012 05:55:11 PM Tom Lane wrote:
Honza Horak <hhorak@redhat.com> writes:
On 06/06/2012 04:50 PM, Andres Freund wrote:
I wonder if the whole issue doesn't require libpq to also try multiple
hardcoded socket locations.
I don't really want to go there.
It would be really nice to have a development psql connect to a distro
installed psql and vice versa without having to specify -h /var/run/psql and -
h /tmp all the time...
I don't find that "nice" at all. Which server did you actually connect
to? How do you control it? You're going to end up needing the -h
switch anyway.
regards, tom lane
On Thursday, June 07, 2012 06:20:32 PM Tom Lane wrote:
Andres Freund <andres@2ndquadrant.com> writes:
On Thursday, June 07, 2012 05:55:11 PM Tom Lane wrote:
Honza Horak <hhorak@redhat.com> writes:
On 06/06/2012 04:50 PM, Andres Freund wrote:
I wonder if the whole issue doesn't require libpq to also try multiple
hardcoded socket locations.I don't really want to go there.
It would be really nice to have a development psql connect to a distro
installed psql and vice versa without having to specify -h /var/run/psql
and - h /tmp all the time...I don't find that "nice" at all. Which server did you actually connect
to? How do you control it? You're going to end up needing the -h
switch anyway.
They can't run on the same port anyway unless you disable listening on
localhost. Changing a single port number is far less effort than typing -h
/var/run/postgresql ;)
Anyway, I am not wed to this, and I don't plan to put work into it so I better
shut up ;)
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On ons, 2012-06-06 at 11:21 -0400, Tom Lane wrote:
I'm not really in favor of making /var/run be the out-of-the-box
default, because it would discriminate against personal/testing
installations (ie, you couldn't set it up without root privileges).
It's a reasonable choice for distro-provided packages, but not so
much for one-off builds --- think about the buildfarm if nothing else.Having said that, if we made it easier to configure things that way
than by patching the source, I bet Martin Pitt isn't going to object.
We already have the ability to configure the Unix socket directory in
postgresql.conf. All you need to do is turn that into a list.
Show quoted text
On Saturday, June 09, 2012 11:43:53 PM Peter Eisentraut wrote:
On ons, 2012-06-06 at 11:21 -0400, Tom Lane wrote:
I'm not really in favor of making /var/run be the out-of-the-box
default, because it would discriminate against personal/testing
installations (ie, you couldn't set it up without root privileges).
It's a reasonable choice for distro-provided packages, but not so
much for one-off builds --- think about the buildfarm if nothing else.Having said that, if we made it easier to configure things that way
than by patching the source, I bet Martin Pitt isn't going to object.We already have the ability to configure the Unix socket directory in
postgresql.conf. All you need to do is turn that into a list.
That doesn't help libpq using clients.
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Peter Eisentraut <peter_e@gmx.net> writes:
We already have the ability to configure the Unix socket directory in
postgresql.conf. All you need to do is turn that into a list.
Um, no, it's not quite that simple. In particular, what do you think
should happen on the client side?
I'm inclined to think that we should (continue to) have a hardwired
"primary" directory, which is the one that libpq is also configured
to look in by default. But we could add a run-time-configured list
of secondary directories to establish sockets in.
regards, tom lane
