location of Unix socket

* 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, Pennsylvania 19026

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, Pennsylvania 19026

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, Pennsylvania 19026

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, Pennsylvania 19026

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, Pennsylvania 19026

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 <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.

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, Pennsylvania 19026

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

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/

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