Re: BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory - Mailing list pgsql-bugs

From Michael Renner
Subject Re: BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory
Date
Msg-id 4ACE3E52.9060907@amd.co.at
Whole thread Raw
In response to Re: BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory
List pgsql-bugs
Tom Lane wrote:

> My current feeling about it is that setting unix_socket_directory as a
> configuration parameter is only useful to those who are deliberately
> trying to hide their postmaster from regular clients, in which case
> the fact that pg_ctl -w fails could be seen as a feature not a bug.
> The way to make it work is of course the same as for any other
> client, eg put PGHOST=/socket/directory in your environment.

Thanks, that is exactly what I wanted to achieve and setting PGHOST
accordingly works fine. Mentioning PGHOST in pg_ctl's
manpage/documentation should make this entirely clear for people who
aren't familiar with the extensive environment variables PostgreSQLs
client library can use. [1]

If this is a viable option I can write a small patch against the
documentation.

> If you want an actually convenient-to-use setup with a nonstandard
> socket directory, the way to do it is to set the socket directory at
> build time (see DEFAULT_PGSOCKET_DIR).  Then you'll have a libpq that
> knows where to look, and the pg_ctl issue goes away.

That'd be also a good alternative for my use case, but I think I'll
stick with PGHOST for now.

best regards,
Michael

[1] I was under the impression that they were psql(1)-specific...

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #5102: Silent IN (list of strings) failure to detect syntax error when list is linewrapped
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory