Re: reload postgresql with invalid pg_hba.conf

On Mon, Sep 18, 2017 at 12:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> jotpe <jotpe(at)posteo(dot)de> 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.

https://www.postgresql.org/docs/9.6/static/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL

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)

https://www.postgresql.org/docs/current/static/config-setting.html#CONFIG-INCLUDES

David J.