Alvaro Herrera <alvherre@commandprompt.com> writes:
> Michael Renner wrote:
>> When using a non-standard unix_socket_directory setting, pg_ctl -w (re)start
>> fails because it checks for the socket file to appear in it's default
>> location.
> Yeah, this has been discussed before. It's been suggested that pg_ctl
> should parse postgresql.conf to figure out the settings, but no one has
> gotten around to it. Feel free to give it a whirl if you're so inclined.
> Hmm, another idea would be to have a new postmaster switch that would
> report the value of any given configuration option. So pg_ctl wouldn't
> have to get into the business of parsing the config file, but would
> simply ask postmaster for the value (which already knows how to parse
> the file).
Neither of those things would fully fix the problem anyway; consider the
possibility that the actual setting came from someplace else, eg the
postmaster command line, or that the current contents of postgresql.conf
are out of sync with the postmaster's actual values (hardly unlikely for
a PGC_POSTMASTER setting). This is not an easy thing to fix.
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.
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.
regards, tom lane