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 



Sat, 18 Nov 2000 00:31:30 +0000
"Oliver Elphick" <olly@lfix.co.uk>
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."

Fri, 17 Nov 2000 16:49:43 -0800
Alfred Perlstein <bright@wintelcom.net>
Re: location of Unix socket
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

Fri, 17 Nov 2000 17:00:16 -0800
Nathan Myers <ncm@zembu.com>
Re: location of Unix socket
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

Fri, 17 Nov 2000 20:28:30 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: location of Unix socket
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

Fri, 17 Nov 2000 21:04:06 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: location of Unix socket 
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/


Sat, 18 Nov 2000 12:03:13 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: location of Unix socket
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

Sat, 18 Nov 2000 09:32:17 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: location of Unix socket
> 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

Fri, 24 Nov 2000 23:15:23 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: location of Unix socket
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/


Sat, 25 Nov 2000 14:43:29 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: location of Unix socket
> 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

Mon, 27 Nov 2000 15:09:46 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: location of Unix socket
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

Mon, 27 Nov 2000 16:00:44 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: location of Unix socket
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/


Mon, 27 Nov 2000 22:02:33 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: location of Unix socket
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

Mon, 27 Nov 2000 16:04:28 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: location of Unix socket 
> 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

Mon, 27 Nov 2000 16:06:50 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: location of Unix socket
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

Mon, 27 Nov 2000 16:20:09 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: location of Unix socket 
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/


Thu, 30 Nov 2000 19:05:09 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: location of Unix socket 
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

Thu, 30 Nov 2000 13:07:53 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: location of Unix socket 