Thread: location of Unix socket
At present the Unix socket's location is hard-coded as /tmp. As a result of a bug report, I have moved it in the Debian package to /var/run/postgresql/. (The bug was that tmpreaper was deleting it and thus blocking new connections.) I suppose that we cannot assume that /var/run exists across all target systems, so could the socket location be made a configurable parameter in 7.1? -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "For by grace are ye saved through faith; and that not of yourselves. It isthe gift of God; not of works, lest any man should boast." Ephesians 2:8,9
* Oliver Elphick <olly@lfix.co.uk> [001117 16:41] wrote: > At present the Unix socket's location is hard-coded as /tmp. > > As a result of a bug report, I have moved it in the Debian package to > /var/run/postgresql/. (The bug was that tmpreaper was deleting it and > thus blocking new connections.) > > I suppose that we cannot assume that /var/run exists across all target > systems, so could the socket location be made a configurable parameter > in 7.1? What about X sockets and ssh-agent sockets, and so on? Where's the source to this thing? :) It would make more sense to fix tempreaper to ignore non regular files. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
On Fri, Nov 17, 2000 at 04:49:43PM -0800, Alfred Perlstein wrote: > * Oliver Elphick <olly@lfix.co.uk> [001117 16:41] wrote: > > At present the Unix socket's location is hard-coded as /tmp. > > > > As a result of a bug report, I have moved it in the Debian package to > > /var/run/postgresql/. (The bug was that tmpreaper was deleting it and > > thus blocking new connections.) > > > > I suppose that we cannot assume that /var/run exists across all target > > systems, so could the socket location be made a configurable parameter > > in 7.1? > > What about X sockets and ssh-agent sockets, and so on? > Where's the source to this thing? :) > > It would make more sense to fix tempreaper to ignore non regular > files. X sockets are in subdirectories, e.g. /tmp/.X11-unix/X0. /tmp is a bad place for this stuff anyway. Nathan Myers ncm@zembu.com
The 7.1 code will the socket location configurable. > At present the Unix socket's location is hard-coded as /tmp. > > As a result of a bug report, I have moved it in the Debian package to > /var/run/postgresql/. (The bug was that tmpreaper was deleting it and > thus blocking new connections.) > > I suppose that we cannot assume that /var/run exists across all target > systems, so could the socket location be made a configurable parameter > in 7.1? > > -- > Oliver Elphick Oliver.Elphick@lfix.co.uk > Isle of Wight http://www.lfix.co.uk/oliver > PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 > GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C > ======================================== > "For by grace are ye saved through faith; and that not > of yourselves. It is the gift of God; not of works, > lest any man should boast." Ephesians 2:8,9 > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Nathan Myers <ncm@zembu.com> writes:
>> * Oliver Elphick <olly@lfix.co.uk> [001117 16:41] wrote:
>>>> could the socket location be made a configurable parameter
>>>> in 7.1?
> /tmp is a bad place for this stuff anyway.
There have been *very long* discussions of this issue in the past,
see for example the threads "flock patch breaks things here" and
"postmaster locking issues" in pghackers around 8/31/98 and 10/10/98.
Could we have some review of the archives before people go off on
a new thread?
The bottom line is that the location of the socket file is a fundamental
part of the client/server protocol. You can't just move it around on
a whim, or your clients will be unable to find your server.
We have just accepted a patch that allows explicit runtime specification
of the socket-file path. (I've got severe doubts about it, because of
this issue --- but at least it doesn't affect people who don't use it.)
But if the socket-file path becomes a site-configuration item then we
will see a lot of complaints. Look at the frequency with which we see
people asking about "Undefined variable client_encoding" notices ---
that proves that those folk are using clients and servers that weren't
configured identically. That notice is at least pretty harmless ...
but if the configuration determines whether or not you can even contact
the server, it's not harmless.
I agree that /tmp was a stupid place to put the files, but we've got to
tread very lightly about moving them, or we'll create worse problems
than we solve.
BTW: a prediction, Oliver: you *will* live to regret making a
distribution-specific change in the socket file location. Dunno
how long it will take, but I foresee bug reports from this.
regards, tom lane
Bruce Momjian writes: > The 7.1 code will the socket location configurable. Btw., are you still about to change it to the directory rather than the file? I'd suggest that you change the GUC parameter to "unix_socket_directory", to be consistent in naming with related parameters. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Yes, I will make the change. > Bruce Momjian writes: > > > The 7.1 code will the socket location configurable. > > Btw., are you still about to change it to the directory rather than the > file? I'd suggest that you change the GUC parameter to > "unix_socket_directory", to be consistent in naming with related > parameters. > > -- > Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian writes: > > > The 7.1 code will the socket location configurable. > > Btw., are you still about to change it to the directory rather than the > file? I'd suggest that you change the GUC parameter to > "unix_socket_directory", to be consistent in naming with related > parameters. Done. I did not change PQunixsocket or the unixsocket PQconnectdb connection option. Should they be changed too? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian writes: > Done. I did not change PQunixsocket or the unixsocket PQconnectdb > connection option. Should they be changed too? They should be removed because PQhost does this now. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> Bruce Momjian writes:
>
> > Done. I did not change PQunixsocket or the unixsocket PQconnectdb
> > connection option. Should they be changed too?
>
> They should be removed because PQhost does this now.
I assume you mean PQunixsocket. As part of the database connection, if
pghost begins with a slash, the value is assigned to pgunixsocket and
pghost is cleared. Here is the code:
/* ---------- * Allow unix socket specification in the host name * ---------- */ if (conn->pghost &&
conn->pghost[0]== '/') { if (conn->pgunixsocket) free(conn->pgunixsocket); conn->pgunixsocket
=conn->pghost; conn->pghost = NULL; }
Am I handling this properly? I hate to be dragging around the unix
socket directory name in pghost for too long and hate to be propogating
the slash test throughout the code.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Bruce Momjian writes: > Am I handling this properly? I hate to be dragging around the unix > socket directory name in pghost for too long and hate to be propogating > the slash test throughout the code. ISTM that you could just do this in connectDBStart() where it actually decides on AF_UNIX. It's just a different place to do it and you don't have to maintain it in two different places (PQconnectdb-style and PQsetdbLogin-style). For symmetry PQhost() should return what was put in as host. Since you cannot put in a unix socket as a separate connection parameter there cannot be a function PQunixsocket to get one out. In fact, ISTM there should not be anything that's explicitly called 'unixsocket'. I don't like the code in fe-connect.c one bit, it's way messed up. Evidently there's even some code in there that allows you to do this: $ psql tcp:postgresql://localhost:5432/peter which is certainly a cool idea, only that it ends up with psql: connectDBStart() -- unknown hostname: J"J"@st Eventually I think the URL-style is the way to go, especially with SSL becoming mainline, so I'd hate to publish too many new functions of questionable value for a feature which is not very well thought out yet. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Well, actually, unixsocket can be specified by PQconnectdb. Sounds like it is a big mess. Care to tame it? I am heading to Japan tomorrow and don't want to leave it 1/2 done. > Bruce Momjian writes: > > > Am I handling this properly? I hate to be dragging around the unix > > socket directory name in pghost for too long and hate to be propogating > > the slash test throughout the code. > > ISTM that you could just do this in connectDBStart() where it actually > decides on AF_UNIX. It's just a different place to do it and you don't > have to maintain it in two different places (PQconnectdb-style and > PQsetdbLogin-style). > > For symmetry PQhost() should return what was put in as host. Since you > cannot put in a unix socket as a separate connection parameter there > cannot be a function PQunixsocket to get one out. In fact, ISTM there > should not be anything that's explicitly called 'unixsocket'. > > I don't like the code in fe-connect.c one bit, it's way messed up. > Evidently there's even some code in there that allows you to do this: > > $ psql tcp:postgresql://localhost:5432/peter > > which is certainly a cool idea, only that it ends up with > > psql: connectDBStart() -- unknown hostname: J"J"@st > > Eventually I think the URL-style is the way to go, especially with SSL > becoming mainline, so I'd hate to publish too many new functions of > questionable value for a feature which is not very well thought out yet. > > -- > Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Am I handling this properly? I hate to be dragging around the unix
> socket directory name in pghost for too long and hate to be propogating
> the slash test throughout the code.
It's probably cleanest to do that the way you are doing it. However,
one could argue we should make PQhost() returnpghost ? pghost : pgunixsocket
which'd make the external behavior compatible with the way one specifies
the connection.
Basically, the idea was to *not* have a distinct unixsocket spec
anywhere in libpq's external API, so that existing apps wouldn't need
a rewrite to support this feature. Keeping unixsocket separate inside
the library is a good idea, but it's independent of the API.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Am I handling this properly? I hate to be dragging around the unix > > socket directory name in pghost for too long and hate to be propogating > > the slash test throughout the code. > > It's probably cleanest to do that the way you are doing it. However, > one could argue we should make PQhost() return > pghost ? pghost : pgunixsocket > which'd make the external behavior compatible with the way one specifies > the connection. > > Basically, the idea was to *not* have a distinct unixsocket spec > anywhere in libpq's external API, so that existing apps wouldn't need > a rewrite to support this feature. Keeping unixsocket separate inside > the library is a good idea, but it's independent of the API. Done. New code: return conn->pghost ? conn->pghost : conn->pgunixsocket; -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Peter Eisentraut <peter_e@gmx.net> writes:
> I don't like the code in fe-connect.c one bit, it's way messed up.
Yes. We've accepted several extremely questionable (not to mention
poorly documented or completely undocumented) "features" in there
recently. If I'd been paying more attention I would've voted against
both the URL patch and the SERVICE patch, as I think they're both
less than fully baked --- and I don't see word one about either in
the libpq SGML documentation.
Someone should probably review the history and either fix or remove
the more dubious patches, before we get stuck having to be
backwards-compatible with bad ideas.
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
> I'm going to disable the URL patch, since it doesn't seem to work and
> breaks legitimate uses of database names with funny characters. The
> service patch seemed kind of useful, but since it's not documented and I
> don't feel like finding out, I think we can let it go the SSL way, i.e.,
> sort out for next release.
Sounds like a plan. The service patch at least doesn't look like it
will cause surprises for anyone who doesn't know about it ...
regards, tom lane
Tom Lane writes: > Peter Eisentraut <peter_e@gmx.net> writes: > > I don't like the code in fe-connect.c one bit, it's way messed up. > > Yes. We've accepted several extremely questionable (not to mention > poorly documented or completely undocumented) "features" in there > recently. If I'd been paying more attention I would've voted against > both the URL patch and the SERVICE patch, as I think they're both > less than fully baked --- and I don't see word one about either in > the libpq SGML documentation. > > Someone should probably review the history and either fix or remove > the more dubious patches, before we get stuck having to be > backwards-compatible with bad ideas. I'm going to disable the URL patch, since it doesn't seem to work and breaks legitimate uses of database names with funny characters. The service patch seemed kind of useful, but since it's not documented and I don't feel like finding out, I think we can let it go the SSL way, i.e., sort out for next release. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/