Обсуждение: BUG #6171: Sockets Issue
The following bug has been logged online: Bug reference: 6171 Logged by: Robert Hopek Email address: rhopek@getnetworks.com PostgreSQL version: 8.1.23 Operating system: CentOS/RHEL Description: Sockets Issue Details: Why do you have the configuration option to change the pgsql socket (which we need to do for our jailed shell environment), but not have psql check the postgresql.conf file for the enablement of that location change so that psql would look there automatically? It seems very counter-productive. While psql, as well as functions in languages like PHP (pg_connect) allow for an override so that you could point it at the new location (when custom coding), existing software, such as phpPgAdmin, are stuck only looking in /tmp for it. We consider it a bug that the server supports a configuration option the clients do not inherently support by checking the configuration of the server.
On 08/20/11 8:31 AM, Robert Hopek wrote: > The following bug has been logged online: > > Bug reference: 6171 > Logged by: Robert Hopek > Email address: rhopek@getnetworks.com > PostgreSQL version: 8.1.23 > Operating system: CentOS/RHEL > Description: Sockets Issue > Details: > > Why do you have the configuration option to change the pgsql socket (which > we need to do for our jailed shell environment), but not have psql check the > postgresql.conf file for the enablement of that location change so that psql > would look there automatically? It seems very counter-productive. While > psql, as well as functions in languages like PHP (pg_connect) allow for an > override so that you could point it at the new location (when custom > coding), existing software, such as phpPgAdmin, are stuck only looking in > /tmp for it. We consider it a bug that the server supports a configuration > option the clients do not inherently support by checking the configuration > of the server. > libpq running in the client user's context usually has no access to the postgresql.conf file which is generally in a mode 700 directory owned by the service account. -- john r pierce N 37, W 122 santa cruz ca mid-left coast
"Robert Hopek" <rhopek@getnetworks.com> writes: > coding), existing software, such as phpPgAdmin, are stuck only looking in > /tmp for it. Did you try host=/custom/path/to/the/socket/? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
"Robert Hopek" <rhopek@getnetworks.com> writes:
> Why do you have the configuration option to change the pgsql socket (which
> we need to do for our jailed shell environment), but not have psql check the
> postgresql.conf file for the enablement of that location change so that psql
> would look there automatically?
How would that work? psql does not know where the server configuration
file is, and would typically not have adequate permissions to read it
anyway.
If you must use a socket location other than /tmp, the most comfortable
way to deal with it is to build custom executables with the correct
locations as their wired-in defaults. This is not really much different
from the situation for a custom port number...
> It seems very counter-productive.
A common reason for using a nondefault connection location is to not
*want* the postmaster to be reached by default-using clients. The
configuration file option does have use-cases, just not yours.
regards, tom lane
"Robert Hopek" <rhopek@getnetworks.com> wrote: > Why do you have the configuration option to change the pgsql > socket (which we need to do for our jailed shell environment), but > not have psql check the postgresql.conf file for the enablement of > that location change so that psql would look there automatically? We have multiple PostgreSQL clusters running on some of our machines. How would your suggestions work in that environment? Are any of the environment variable helpful?: http://www.postgresql.org/docs/9.0/interactive/libpq-envars.html -Kevin