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 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
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.confit 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
Import Notes
Reply to msg id not found: Pine.LNX.4.30.0103301703010.1063-100000@peter.localdomain | Resolved by subject fallback
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.confit 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/
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/