reload postgresql with invalid pg_hba.conf
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t130803psql -h localhost -U postgresBuilt from patchset v3 (message #3), July 27, 2026 at 10:16 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t130803_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t130803_3 && git checkout t130803_3Patchset v3 (message #3) is on t130803_3
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
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.
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.
"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