Re: [patch] [doc] Clarify that signal functions have no feedback - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [patch] [doc] Clarify that signal functions have no feedback
Date
Msg-id 633cc9f1-d942-ceec-f8fe-17bcc21772d2@iki.fi
Whole thread Raw
In response to Re: [patch] [doc] Clarify that signal functions have no feedback  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: [patch] [doc] Clarify that signal functions have no feedback  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
On 02/11/2020 18:02, David G. Johnston wrote:
> diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> index bf6004f321..43bc2cf086 100644
> --- a/doc/src/sgml/func.sgml
> +++ b/doc/src/sgml/func.sgml
> @@ -23892,7 +23892,8 @@ SELECT collation for ('foo' COLLATE "de_DE");
>  
>     <para>
>      The functions shown in <xref
> -    linkend="functions-admin-signal-table"/> send control signals to
> +    linkend="functions-admin-signal-table"/> send uni-directional
> +    control signals to
>      other server processes.  Use of these functions is restricted to
>      superusers by default but access may be granted to others using
>      <command>GRANT</command>, with noted exceptions.

The "uni-directional" sounds a bit redundant, "send" implies that it's 
uni-directional I think.

> @@ -23900,7 +23901,8 @@ SELECT collation for ('foo' COLLATE "de_DE");
>  
>     <para>
>      Each of these functions returns <literal>true</literal> if
> -    successful and <literal>false</literal> otherwise.
> +    the signal was successfully sent and <literal>false</literal>
> +    if the sending of the signal failed.
>     </para>

This is a good clarification.

>     <table id="functions-admin-signal-table">
> @@ -23948,7 +23950,11 @@ SELECT collation for ('foo' COLLATE "de_DE");
>          server to reload their configuration files.  (This is initiated by
>          sending a <systemitem>SIGHUP</systemitem> signal to the postmaster
>          process, which in turn sends <systemitem>SIGHUP</systemitem> to each
> -        of its children.)
> +        of its children.)  Inspection of the relevant
> +        <link linkend="view-pg-file-settings">pg_file_settings</link>
> +        or
> +        <link linkend="view-pg-hba-file-rules">pg_hba_file_rules</link> views
> +        is recommended after making changes but before signaling the server.
>         </para></entry>
>        </row>

I don't understand this recommendation. What is the user supposed to 
look for in those views? And why before signaling the server?

[me reads what those views do]. Oh, I see, the idea is that you can use 
those views to check the configuration for errors, before applying the 
changes. How about this:

You can use the <link 
linkend="view-pg-file-settings">pg_file_settings</link> and <link 
linkend="view-pg-hba-file-rules">pg_hba_file_rules</link> views to check 
the configuration files for possible errors, before reloading.

- Heikki



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_proc.dat "proargmodes is not a 1-D char array"
Next
From: Peter Eisentraut
Date:
Subject: Re: Hash support for row types