Re: [HACKERS] Should we eliminate or reduce HUP from docs?

2017-03-16 Thread Bruce Momjian 
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 
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  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

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

2017-03-10 Thread David G. Johnston 
On Fri, Mar 10, 2017 at 3:51 PM, Alvaro Herrera 
wrote:

> David G. Johnston wrote:
> > On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera <
> alvhe...@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.

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

2017-03-10 Thread Alvaro Herrera 
David G. Johnston wrote:
> On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera 
> 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 Herrerahttps://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

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

2017-03-10 Thread David G. Johnston 
On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera 
wrote:

> David G. Johnston wrote:
> > On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera <
> alvhe...@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.

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

2017-03-10 Thread Alvaro Herrera 
David G. Johnston wrote:
> On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera 
> 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 Herrerahttps://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

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

2017-03-10 Thread David G. Johnston 
On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera 
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.

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

2017-03-10 Thread Alvaro Herrera 
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 Herrerahttps://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

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

2017-03-10 Thread Andres Freund 
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

[HACKERS] Should we eliminate or reduce HUP from docs?

2017-03-10 Thread Joshua D. Drake 

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.


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