Обсуждение: [GENERAL] reload postgresql with invalid pg_hba.conf
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? Best regards. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
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.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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)
David J.
Вложения
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Mon, Sep 18, 2017 at 12:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
Yeah. After more thought, it occurs to me that now that we did f13ea95f9,
we could improve matters by extending that concept: the postmaster could
record its last reload time in postmaster.pid along with a success/failure
flag, and pg_ctl could watch that file to detect what happened.
(No, I'm not volunteering to write the patch.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general