Search Postgresql Archives

Re: reload postgresql with invalid pg_hba.conf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 18, 2017 at 12:36 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
jotpe <jotpe@xxxxxxxxx> writes:
> A system administration applied an invalid line into the pg_hba.conf
> file and called "service postgresql reload". Since that command doesn't
> return any error and leaves with exit code 0 it seams that new
> configuration was applied.

> Of course postgresql added a warning to the log file: "pg_hba.conf not
> reloaded".
> But even when I execute SELECT pg_reload_conf(), true is returned.

> Is this the desired behavior?

I wouldn't say it's desired behavior, exactly, but there's no very
good way to improve it.  pg_ctl has no visibility into what the postmaster
is thinking.

The function signature (and docs) for pg_reload_conf makes the OPs interpretation understandable.  The docs and intuition would lead one to assume that "true" means the reload was successful and "false" means it was not (possibly with reasons emitted as notices/warnings/errors).​  But all it tells us is whether a signal "was sent" and not whether it was successfully acted upon by the other party.

Something like the attached makes this dynamic stand out.


Cancel and terminate backends do have conditional return values so those two seem OK.

pg_rotate_logfile() I suppose might want to be clarified here as well though I suspect it is less prone to complications that pg_reload_conf is.

The description of pg_ctl doesn't lead to the same kind of assumptions being made (i.e., it only speaks of sending a signal and has no declared return value) though maybe an additional sentence wouldn't hurt...?

The docs on configuring the server to speak to this overall flow and what happens when invalid values are encountered (i.e., they are ignored)


David J.

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 641b3b8f4e..9ac7bf1e87 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -18373,7 +18373,7 @@ SELECT set_config('log_statement_stats', 'off', false);
         <literal><function>pg_reload_conf()</function></literal>
         </entry>
        <entry><type>boolean</type></entry>
-       <entry>Cause server processes to reload their configuration files</entry>
+       <entry>Cause server processes to attempt reloading their configuration files</entry>
       </row>
       <row>
        <entry>
@@ -18420,7 +18420,10 @@ SELECT set_config('log_statement_stats', 'off', false);
    <para>
     <function>pg_reload_conf</> sends a <systemitem>SIGHUP</> signal
     to the server, causing configuration files
-    to be reloaded by all server processes.
+    to be reloaded by all server processes.  The return value only indicates
+    whether the signal was sent successfully to the postmaster.  It does not
+    say whether the reload was performed and propogated successfully by
+    the postmaster.
    </para>
 
    <para>
-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux