Re: Ability to listen on two unix sockets - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: Ability to listen on two unix sockets |
Date | |
Msg-id | 10535.1338993522@sss.pgh.pa.us Whole thread Raw |
In response to | Re: Ability to listen on two unix sockets (Florian Pflug <fgp@phlo.org>) |
Responses |
Re: Ability to listen on two unix sockets
Re: Ability to listen on two unix sockets Re: Ability to listen on two unix sockets Re: Ability to listen on two unix sockets |
List | pgsql-hackers |
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
pgsql-hackers by date: