Thread

1. unix_socket_directory isn't used by all bin tools

   PostgreSQL Bugs List <pgsql-bugs@postgresql.org> — 2001-03-30T13:35:37Z

   Jerome Alet (alet@unice.fr) reports a bug with a severity of 2
   The lower the number the more severe it is.
   
   Short Description
   unix_socket_directory isn't used by all bin tools
   
   Long Description
   I use 7.1RC1
   
   I've defined unix_socket_directory to be /var/lib/postgres
   in /var/lib/data/postgresql.conf
   
   it seems that at least createuser doesn't take care of this directory setting, because it searches the socket exclusively in /tmp, so it fails asking whether postmaster is running or not.
   
   if I remove the unix_socket_directory setting from postgresql.conf all works fine.
   
   System: GNU/LInux Debian Woody
   Kernel 2.4.2
   Glibc 2.2.2
   
   bye,
   
   Jerome Alet
   
   Sample Code
   
   
   No file was uploaded with this report
   
   
   

2. Re: unix_socket_directory isn't used by all bin tools

   Jerome Alet <alet@unice.fr> — 2001-03-30T14:59:08Z

   On Fri, 30 Mar 2001, Peter Eisentraut wrote:
   
   > > Jerome Alet (alet@unice.fr) reports a bug with a severity of 2
   > > The lower the number the more severe it is.
   > 
   > > I've defined unix_socket_directory to be /var/lib/postgres
   > > in /var/lib/data/postgresql.conf
   > >
   > > it seems that at least createuser doesn't take care of this directory
   > > setting, because it searches the socket exclusively in /tmp, so it
   > > fails asking whether postmaster is running or not.
   > 
   > The configuration file is only for the server; the clients don't see it.
   > Client tools can use the PGHOST environment variable or the -h option, or
   > whatever else the client has implemented.
   
   I disagree partially, correct me if I'm wrong:
   
   Unix domain sockets are not available accross the network, so in this
   particular case (postmaster not listening on tcp) the client and the
   server are on the same machine, it's mandatory. That's why I think that
   these programs should take care of the server's configuration if it's
   available (and no -h or PGHOST option)
   
   hoping this clarifies what I meant.
   
   bye,
   
   Jerome Alet
   
   
   

3. Re: unix_socket_directory isn't used by all bin tools

   Peter Eisentraut <peter_e@gmx.net> — 2001-03-30T15:04:58Z

   > Jerome Alet (alet@unice.fr) reports a bug with a severity of 2
   > The lower the number the more severe it is.
   
   > I've defined unix_socket_directory to be /var/lib/postgres
   > in /var/lib/data/postgresql.conf
   >
   > it seems that at least createuser doesn't take care of this directory
   > setting, because it searches the socket exclusively in /tmp, so it
   > fails asking whether postmaster is running or not.
   
   The configuration file is only for the server; the clients don't see it.
   Client tools can use the PGHOST environment variable or the -h option, or
   whatever else the client has implemented.
   
   -- 
   Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/
   
   
   

4. Re: unix_socket_directory isn't used by all bin tools

   Peter Eisentraut <peter_e@gmx.net> — 2001-03-31T08:38:29Z

   Jerome Alet writes:
   
   > > The configuration file is only for the server; the clients don't see it.
   > > Client tools can use the PGHOST environment variable or the -h option, or
   > > whatever else the client has implemented.
   >
   > I disagree partially, correct me if I'm wrong:
   >
   > Unix domain sockets are not available accross the network, so in this
   > particular case (postmaster not listening on tcp) the client and the
   > server are on the same machine, it's mandatory. That's why I think that
   > these programs should take care of the server's configuration if it's
   > available (and no -h or PGHOST option)
   
   I'm not sure exactly what you disagree with.  The feature "configuration
   file" is certainly operating as designed and as documented.  If you want
   to propose an additional feature, then you're free to do that, but there
   is no way we'll let client programs read the server's configuration file,
   they just don't have a business there (if they can find it at all).
   
   If you want to change the location of the local socket file for both
   client and server then you can make it a compile-time change.  The primary
   reason for it being a run-time option, too, was for "virtual hosting"
   setups, and in that case it's doubtful whether a global client-readable
   configuration file would even be appropriate.
   
   -- 
   Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/