Re: [patch] [doc] Clarify that signal functions have no feedback
От | Heikki Linnakangas |
---|---|
Тема | Re: [patch] [doc] Clarify that signal functions have no feedback |
Дата | |
Msg-id | 633cc9f1-d942-ceec-f8fe-17bcc21772d2@iki.fi обсуждение исходный текст |
Ответ на | Re: [patch] [doc] Clarify that signal functions have no feedback ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: [patch] [doc] Clarify that signal functions have no feedback
|
Список | 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 по дате отправления: