On Mon, Sep 18, 2017 at 12:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
jotpe <jotpe@posteo.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.
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)
