Обсуждение: 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.renner@amd.co.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.
Re: BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory
От
Alvaro Herrera
Дата:
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@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
Re: BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory
От
Michael Renner
Дата:
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...
Re: BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory
От
Alvaro Herrera
Дата:
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.
Re: BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory
От
Michael Renner
Дата:
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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.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@momjian.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@momjian.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@momjian.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. + Index: doc/src/sgml/ref/pg_ctl-ref.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml,v retrieving revision 1.47 diff -c -c -r1.47 pg_ctl-ref.sgml *** doc/src/sgml/ref/pg_ctl-ref.sgml 10 Dec 2009 06:32:28 -0000 1.47 --- doc/src/sgml/ref/pg_ctl-ref.sgml 22 Feb 2010 22:28:14 -0000 *************** *** 393,406 **** </varlistentry> <varlistentry> <term><envar>PGPORT</envar></term> <listitem> <para> ! Default port for <xref linkend="app-psql"> (used by the -w option). </para> </listitem> </varlistentry> </variablelist> <para> --- 393,418 ---- </varlistentry> <varlistentry> + <term><envar>PGHOST</envar></term> + + <listitem> + <para> + Default hostname or Unix-domain socket location for <xref + linkend="app-psql"> (used by the -w option). + </para> + </listitem> + </varlistentry> + + <varlistentry> <term><envar>PGPORT</envar></term> <listitem> <para> ! Default port number for <xref linkend="app-psql"> (used by the -w option). </para> </listitem> </varlistentry> + </variablelist> <para> Index: doc/src/sgml/ref/postgres-ref.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ref/postgres-ref.sgml,v retrieving revision 1.51 diff -c -c -r1.51 postgres-ref.sgml *** doc/src/sgml/ref/postgres-ref.sgml 9 Jul 2007 01:08:09 -0000 1.51 --- doc/src/sgml/ref/postgres-ref.sgml 22 Feb 2010 22:28:14 -0000 *************** *** 579,585 **** <listitem> <para> ! Default port (preferably set in the configuration file) </para> </listitem> </varlistentry> --- 579,585 ---- <listitem> <para> ! Default port number (preferably set in the configuration file) </para> </listitem> </varlistentry>
Re: BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory
От
Michael Renner
Дата:
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