Thread: [HACKERS] Should we eliminate or reduce HUP from docs?
Hello, I am a bad speaker, I am writing a talk three weeks before the conference (as opposed to on the plane). I noticed in the docs we still reference the passing of SIGHUP for reloading conf file but we now have pg_reload_conf(); It seems the use of pg_reload_conf() would provide a better canonical interface to our users. Especially those users who are not used to interacting with the OS (Windows, Oracle etc...) for databases. Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them. Unless otherwise stated, opinions are my own.
Hi, On 2017-03-10 11:57:30 -0800, Joshua D. Drake wrote: > I am a bad speaker, I am writing a talk three weeks before the conference > (as opposed to on the plane). I noticed in the docs we still reference the > passing of SIGHUP for reloading conf file but we now have pg_reload_conf(); > > It seems the use of pg_reload_conf() would provide a better canonical > interface to our users. Especially those users who are not used to > interacting with the OS (Windows, Oracle etc...) for databases. -1 HUP is useful for external control. Doesn't require to have a valid log-in into the database. Regards, Andres
Joshua D. Drake wrote: > I am a bad speaker, I am writing a talk three weeks before the conference > (as opposed to on the plane). Hah. > I noticed in the docs we still reference the > passing of SIGHUP for reloading conf file but we now have pg_reload_conf(); > > It seems the use of pg_reload_conf() would provide a better canonical > interface to our users. Especially those users who are not used to > interacting with the OS (Windows, Oracle etc...) for databases. There are several ways to cause a config file reload (pg_ctl reload, pg_reload_conf, direct SIGHUP). We could have a section in docs listing them all, and then all the other places that say a reload needs to occur simply refer the reader to that section. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Joshua D. Drake wrote:
> I am a bad speaker, I am writing a talk three weeks before the conference
> (as opposed to on the plane).
Hah.
> I noticed in the docs we still reference the
> passing of SIGHUP for reloading conf file but we now have pg_reload_conf();
>
> It seems the use of pg_reload_conf() would provide a better canonical
> interface to our users. Especially those users who are not used to
> interacting with the OS (Windows, Oracle etc...) for databases.
There are several ways to cause a config file reload (pg_ctl reload,
pg_reload_conf, direct SIGHUP). We could have a section in docs listing
them all, and then all the other places that say a reload needs to occur
simply refer the reader to that section.
19.1.2 contains a fairly comprehensive coverage of the topic - but postgres.conf is not the only thing that gets reloaded. Specifically, "Client Authentication" (chapter 20) is also affected.
One theory would be to consider "configuration reload" part of "18. Server ... Operation" and document the mechanics there with forward references to 19/Configuration and 20/Authentication. The existing content in those chapters discussing reload would then send the reader back to 18 for "how to reload" and just state "when to reload" in their particular situations.
Any other spots that warrant the same treatment?
If we are going to touch this area up it might be worth a fresh consideration of index entries too.
David J.
David G. Johnston wrote: > On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera <alvherre@2ndquadrant.com> > wrote: > > There are several ways to cause a config file reload (pg_ctl reload, > > pg_reload_conf, direct SIGHUP). We could have a section in docs listing > > them all, and then all the other places that say a reload needs to occur > > simply refer the reader to that section. > > 19.1.2 contains a fairly comprehensive coverage of the topic - but > postgres.conf is not the only thing that gets reloaded. Specifically, > "Client Authentication" (chapter 20) is also affected. I think we could split 19.1.2 in two parts, where the first one is the current content minus the paragraph "The configuration file is reread". We'd create "19.1.3 Configuration File Reloads" to contain that paragraph, perhaps not with the exact current wording. > One theory would be to consider "configuration reload" part of "18. Server > ... Operation" and document the mechanics there with forward references to > 19/Configuration and 20/Authentication. Dunno. Given that other configuration elements such as config file placement are already in chapter 19, it seems strange to put reloading behavior in 18. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
David G. Johnston wrote:
> On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
> wrote:
> > There are several ways to cause a config file reload (pg_ctl reload,
> > pg_reload_conf, direct SIGHUP). We could have a section in docs listing
> > them all, and then all the other places that say a reload needs to occur
> > simply refer the reader to that section.
>
> 19.1.2 contains a fairly comprehensive coverage of the topic - but
> postgres.conf is not the only thing that gets reloaded. Specifically,
> "Client Authentication" (chapter 20) is also affected.
I think we could split 19.1.2 in two parts, where the first one is the
current content minus the paragraph "The configuration file is reread".
We'd create "19.1.3 Configuration File Reloads" to contain that
paragraph, perhaps not with the exact current wording.
If only 19 and 20 need it I would say its a coin-toss.
> One theory would be to consider "configuration reload" part of "18. Server
> ... Operation" and document the mechanics there with forward references to
> 19/Configuration and 20/Authentication.
Dunno. Given that other configuration elements such as config file
placement are already in chapter 19, it seems strange to put reloading
behavior in 18.
It wouldn't be hateful to cross link to 19 from 20 - but assuming pg_reload_conf() impacts pg_hba.conf (I don't know off-hand) the paragraph
"""
The pg_hba.conf file is read on start-up and when the main server process receives a SIGHUP signal. If you edit the file on an active system, you will need to signal the postmaster (using pg_ctl reload or kill -HUP) to make it re-read the file.
"""
is incomplete.
Is "kill" portable?
The order or some of these items is interesting but given the general lack of field complaints and questions it mustn't be confusion inducing. Even this thread isn't an actual complaint but rather concern about signals in general. Pulling the relevant paragraph out to its own section in 19.1 was my first reaction as well and has the merit of simplicity.
David J.
David G. Johnston wrote: > On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera <alvherre@2ndquadrant.com> > wrote: > > > I think we could split 19.1.2 in two parts, where the first one is the > > current content minus the paragraph "The configuration file is reread". > > We'd create "19.1.3 Configuration File Reloads" to contain that > > paragraph, perhaps not with the exact current wording. > > If only 19 and 20 need it I would say its a coin-toss. Well, I think it's better to back-reference chapter 19 from 20 than the other way around. > > Dunno. Given that other configuration elements such as config file > > placement are already in chapter 19, it seems strange to put reloading > > behavior in 18. > > > It wouldn't be hateful to cross link to 19 from 20 - but assuming > pg_reload_conf() impacts pg_hba.conf (I don't know off-hand) (Yes it does.) > the paragraph > > """ > The pg_hba.conf file is read on start-up and when the main server process > receives a SIGHUP signal. If you edit the file on an active system, you > will need to signal the postmaster (using pg_ctl reload or kill -HUP) to > make it re-read the file. > """ > > is incomplete. Sure. We can just reword that along the lines of " ... and when a reload signal is received, see 19.1.3". Don't you like that? > Is "kill" portable? It isn't -- it doesn't work on Windows, RDS. > The order or some of these items is interesting but given the general lack > of field complaints and questions it mustn't be confusion inducing. Even > this thread isn't an actual complaint but rather concern about signals in > general. Pulling the relevant paragraph out to its own section in 19.1 was > my first reaction as well and has the merit of simplicity. Simplicity FTW. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
David G. Johnston wrote:
> On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
> is incomplete.
Sure. We can just reword that along the lines of " ... and when a
reload signal is received, see 19.1.3". Don't you like that?
WFM
> The order or some of these items is interesting but given the general lack
> of field complaints and questions it mustn't be confusion inducing. Even
> this thread isn't an actual complaint but rather concern about signals in
> general. Pulling the relevant paragraph out to its own section in 19.1 was
> my first reaction as well and has the merit of simplicity.
Simplicity FTW.
WFM
David J.
On Fri, Mar 10, 2017 at 11:57:30AM -0800, Joshua Drake wrote: > Hello, > > I am a bad speaker, I am writing a talk three weeks before the conference > (as opposed to on the plane). I noticed in the docs we still reference the > passing of SIGHUP for reloading conf file but we now have pg_reload_conf(); > > It seems the use of pg_reload_conf() would provide a better canonical > interface to our users. Especially those users who are not used to > interacting with the OS (Windows, Oracle etc...) for databases. FYI, I did apply this patch for PG 10: commit 10c064ce4dad088ba2d8b978bff6009b9f22dc3aAuthor: Bruce Momjian <bruce@momjian.us>Date: Tue Oct 25 11:26:15 2016 -0400 Consistently mention 'SELECT pg_reload_conf()' in config files Previously we only mentioned SIGHUP and 'pg_ctlreload' in postgresql.conf and pg_hba.conf. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +