Re: Ability to listen on two unix sockets

On Wed, Jun 6, 2012 at 1:55 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Jun 6, 2012 at 10:38 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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