Should we eliminate or reduce HUP from docs?

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Mar 10, 2017 at 3:51 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:

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 10c064ce4dad088ba2d8b978bff6009b9f22dc3a
Author: 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_ctl reload' 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 +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers