commit f77b42a4d01ba59017e01d30c145eb4a78f83565 Author: David G. Johnston Date: Mon Nov 2 15:55:39 2020 +0000 Clarify the signal functions have no feedback Bug# 16652 complains that the definition of success for pg_reload_conf doesn't include the outcome of actually reloading the configuration files. While this is a fairly easy gap to cross given knowledge of signals, being more explicit here doesn't hurt. Additionally, because of the special nature of pg_reload_conf, add links to the various locations where information related to the success or failure of a reload can be found. 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"); The functions shown in 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 GRANT, with noted exceptions. @@ -23900,7 +23901,8 @@ SELECT collation for ('foo' COLLATE "de_DE"); Each of these functions returns true if - successful and false otherwise. + the signal was successfully sent and false + if the sending of the signal failed. @@ -23948,7 +23950,11 @@ SELECT collation for ('foo' COLLATE "de_DE"); server to reload their configuration files. (This is initiated by sending a SIGHUP signal to the postmaster process, which in turn sends SIGHUP to each - of its children.) + of its children.) Inspection of the relevant + pg_file_settings + or + pg_hba_file_rules views + is recommended after making changes but before signaling the server.