Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Z4gi5-0007UK-Or for pgsql-docs@arkaria.postgresql.org; Tue, 16 Jun 2015 02:34:45 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Z4gi4-0001ZV-2E for pgsql-docs@arkaria.postgresql.org; Tue, 16 Jun 2015 02:34:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Z4gi3-0001ZO-44 for pgsql-docs@postgresql.org; Tue, 16 Jun 2015 02:34:43 +0000 Received: from mail-la0-x22b.google.com ([2a00:1450:4010:c03::22b]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Z4ghu-00042i-Kk for pgsql-docs@postgresql.org; Tue, 16 Jun 2015 02:34:42 +0000 Received: by labbc20 with SMTP id bc20so2051760lab.1 for ; Mon, 15 Jun 2015 19:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TTNobBtMaTfP9Rt6Hzij/woKiUFSV5rfTFZoKHqgFb4=; b=Q0/OYxSRdv7euX2tHiDb9P4ktuBRFmizG83JcVYy3tCkloM2wjQQLBaKdST2mOpxdk oN9MnIYZ9MIud0cjz/s8o8h+MZRaH+VkrEFG2YyUSiWGe0AzM8uAkb60Lkbdh4oF13bw n+OkxWDXIgA4TVIlW5RArbsitxzXLXME7PCPQgP5uVvryJb24U0RNrYgkOgYc2Mbos/9 mhhVxBeNs2GNR5TiJ7ZzfoucF4vAa68jBYZAKKjpBP4hzRs/bITa+hmjNdy3s+QDrRaB CasiDfVWHWpIJACxml1gRr8egbVeu/AjTBXfPfmD52XKhOquQKIFqjP+fwOrf3qY9SOV yBTg== MIME-Version: 1.0 X-Received: by 10.152.20.99 with SMTP id m3mr30092611lae.20.1434422073340; Mon, 15 Jun 2015 19:34:33 -0700 (PDT) Received: by 10.25.37.132 with HTTP; Mon, 15 Jun 2015 19:34:33 -0700 (PDT) In-Reply-To: References: <557F3C7C.2010802@timbira.com.br> Date: Mon, 15 Jun 2015 19:34:33 -0700 Message-ID: Subject: Re: "Alter system" command documentation From: Jeff Janes To: "David G. Johnston" Cc: Euler Taveira , "pgsql-docs@postgresql.org" Content-Type: multipart/alternative; boundary=089e013d192423bb0d0518996a96 X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org --089e013d192423bb0d0518996a96 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 15, 2015 at 2:10 PM, David G. Johnston < david.g.johnston@gmail.com> wrote: > On Mon, Jun 15, 2015 at 4:58 PM, Euler Taveira > wrote: > >> On 15-06-2015 13:32, Jeff Janes wrote: >> > From http://www.postgresql.org/docs/current/static/sql-altersystem.htm= l >> > >> > "Values set with ALTER SYSTEM will be effective after the next server >> > configuration reload (SIGHUP or pg_ctl reload), or after the next serv= er >> > restart in the case of parameters that can only be changed at server >> start." >> > >> > Isn't it unfortunate that the command used for changing the >> > configuration file from within SQL mentions SIGHUP and pg_ctl reload, >> > but not "select pg_reload_conf();", as a way to activate that change? >> > >> SIGHUP is an implementation detail. If I were to change that sentence, >> my preference is replace SIGHUP with pg_reload_conf. >> =E2=80=8B >> > > =E2=80=8BI =E2=80=8B > disagree on SIGHUP being an implementation detail. > =E2=80=8B > =E2=80=8B Using signals in IPC (inter-process communication) is a public= API that > should be documented when applicable. Yes, various command-line and SQL > commands and functions have been provided so that one does not have to us= e > raw signals but they are still part of the public API for the application= . > > Adding mention of pg_reload_conf may be warranted (probably is but I > haven't made an independent evaluation) but removing SIGHUP is a separate > concern and one that doesn't seem necessary. > Certainly SIGHUP should be (and is) documented elsewhere in the docs. But there is no reason for it to be documented on this particular page, which is about a command we added specifically so you can make config changes without having to drop into an OS shell. If we are going to mention (on this particularly page) only some of the ways to trigger a reload, certainly the way that also doesn't require dropping into an OS shell should be among the ones included. I don't know that pg_reload_conf() should be the only one we mention here. But surely it should not be the only one we don't mention. The cleanest way would probably be to mention this in addition to the other two, as to mention only this one might imply the others don't work for this purpose. We could not mention any of them and let the person go read the other parts of the docs on their own to find the methods used to trigger a reload, but that seems legalistic and unhelpful. In any event, I was mildly annoyed to go read the docs about a feature I was aware of but never needed to use it before, and have it tell me about two things which I already knew about but which aren't very useful in this context (that is, not having convenient shell access at the moment), while not telling me about the third option which actually is useful in this context but which I didn't know how to spell (because I almost always use the other two methods instead--except for right now). Cheers, Jeff --089e013d192423bb0d0518996a96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 15, 2015 at 2:10 PM, David G. Johnston <david.g.johnston@= gmail.com> wrote:
On Mon, Jun 15, 2015 at 4:58 PM, Euler = Taveira <= ;euler@timbira.co= m.br> wrote:
<= span class=3D"">
On 15-06-2015 13:32, Jeff Janes = wrote:
> From http://www.postgresql.or= g/docs/current/static/sql-altersystem.html
>
> "Values set with ALTER SYSTEM will be effective after the next se= rver
> configuration reload (SIGHUP or pg_ctl reload), or after the next serv= er
> restart in the case of parameters that can only be changed at server s= tart."
>
> Isn't it unfortunate that the command used for changing the
> configuration file from within SQL mentions SIGHUP and pg_ctl reload,<= br> > but not "select pg_reload_conf();", as a way to activate tha= t change?
>
SIGHUP is an implementation detail. If I were to change that se= ntence,
my preference is replace SIGHUP with pg_reload_conf.
=E2=80=8B
<= div>
=E2=80=8BI =E2=80=8B
disagree on SIGHUP being an implementation detail.
=E2=80=8B
=E2=80=8B =C2=A0Using signals in IP= C (inter-process communication) is a public API that should be documented w= hen applicable.=C2=A0 Yes, various command-line and SQL commands and functi= ons have been provided so that one does not have to use raw signals but the= y are still part of the public API for the application.
<= div>

Adding mention of pg= _reload_conf may be warranted (probably is but I haven't made an indepe= ndent evaluation) but removing SIGHUP is a separate concern and one that do= esn't seem necessary.
=

Certainly SIGHUP should be (and is) documented elsewher= e in the docs.=C2=A0 But there is no reason for it to be documented on this= particular page, which is about a command we added specifically so you can= make config changes without having to drop into an OS shell.=C2=A0 If we a= re going to mention (on this particularly page) only some of the ways to tr= igger a reload, certainly the way that also doesn't require dropping in= to an OS shell should be among the ones included. I don't know that=C2= =A0pg_reload_conf() = should be the only one we mention here.=C2=A0 But surely it should not be t= he only one we don't mention. =C2=A0

The cleanest way would probably be = to mention this in addition to the other two, as to mention only this one m= ight imply the others don't work for this purpose.=C2=A0 We could not m= ention any of them and let the person go read the other parts of the docs o= n their own to find the methods used to trigger a reload, but that seems le= galistic and unhelpful.

In any event, I was= mildly annoyed to go read the docs about a feature I was aware of but neve= r needed to use it before, and have it tell me about two things which I alr= eady knew about but which aren't very useful in this context (that is, = not having convenient shell access at the moment), while not telling me abo= ut the third option which actually is useful in this context but which I di= dn't know how to spell (because I almost always use the other two metho= ds instead--except for right now).

Cheers,

Jeff
--089e013d192423bb0d0518996a96--