Thread: unix_socket_directory isn't used by all bin tools
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 exclusivelyin /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
> 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/
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
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/