BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory

The following bug has been logged online:

Bug reference: 5103
Logged by: Michael Renner
Email address: michael(dot)renner(at)amd(dot)co(dot)at
PostgreSQL version: HEAD
Operating system: Linux
Description: "pg_ctl -w (re)start" fails with custom
unix_socket_directory
Details:

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.

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).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre(at)commandprompt(dot)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

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...

Michael Renner wrote:

> 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]

Yeah, this has been complained about many, many times.

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

I think the patch we need here is something that creates a separate
manpage for the libpq environment variables, and some kind of note in
each and every libpq-using program referring the user to that page.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Michael Renner wrote:
>
>> 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]
>
> Yeah, this has been complained about many, many times.

Usually an indicator that it need's fixing, eh? ;)

>> If this is a viable option I can write a small patch against the
>> documentation.
>
> I think the patch we need here is something that creates a separate
> manpage for the libpq environment variables, and some kind of note in
> each and every libpq-using program referring the user to that page.

Looking through the available variables probably only PGHOST seems to be
of interest for pg_ctl's purposes; psql's manpage already refers to The
Documentation for further variables and information. What's needed in
pg_ctl's case is just a pointer for the uninformed, at least for me
that'd have sufficed.

best regards,
Michael

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.

Is this current TODO item incorrect? Should it be removed?

Have pg_ctl look at PGHOST in case it is a socket directory?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> 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.

> Is this current TODO item incorrect? Should it be removed?

> Have pg_ctl look at PGHOST in case it is a socket directory?

I dunno why that's there, but it sure *looks* like it's clueless
about the actual behavior of pg_ctl ...

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > 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.
>
> > Is this current TODO item incorrect? Should it be removed?
>
> > Have pg_ctl look at PGHOST in case it is a socket directory?
>
> I dunno why that's there, but it sure *looks* like it's clueless
> about the actual behavior of pg_ctl ...

Thanks, removed.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Michael Renner wrote:
> Alvaro Herrera wrote:
> > Michael Renner wrote:
> >
> >> 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]
> >
> > Yeah, this has been complained about many, many times.
>
> Usually an indicator that it need's fixing, eh? ;)
>
> >> If this is a viable option I can write a small patch against the
> >> documentation.
> >
> > I think the patch we need here is something that creates a separate
> > manpage for the libpq environment variables, and some kind of note in
> > each and every libpq-using program referring the user to that page.
>
> Looking through the available variables probably only PGHOST seems to be
> of interest for pg_ctl's purposes; psql's manpage already refers to The
> Documentation for further variables and information. What's needed in
> pg_ctl's case is just a pointer for the uninformed, at least for me
> that'd have sufficed.

Based on your suggestion, I have documented the use of PGHOST by pg_ctl
with the attached patch. I specifically mentioned the socket location.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +

On 22.02.2010 23:38, Bruce Momjian wrote:
> Michael Renner wrote:
>
>> Looking through the available variables probably only PGHOST seems to be
>> of interest for pg_ctl's purposes; psql's manpage already refers to The
>> Documentation for further variables and information. What's needed in
>> pg_ctl's case is just a pointer for the uninformed, at least for me
>> that'd have sufficed.
>
> Based on your suggestion, I have documented the use of PGHOST by pg_ctl
> with the attached patch. I specifically mentioned the socket location.

Thanks, highly appreciated!

best regards,
Michael Renner