From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | "mail(at)goessmann(dot)io" <mail(at)goessmann(dot)io>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #16652: SELECT pg_reload_conf(); returning true despite loading config has failed |
Date: | 2020-10-03 20:02:24 |
Message-ID: | CAKFQuwbofsP0MOQWEisfMM5=p6gwbLq-NULL67Xkw3vep_ygUg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Saturday, October 3, 2020, PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 16652
> Logged by: Christoph Gößmann
> Email address: mail(at)goessmann(dot)io
> PostgreSQL version: 11.4
> Operating system: CentOS Linux 7
> Description:
>
> The command "SELECT pg_reload_conf();" returns TRUE, letting the admin
> believe that the new configuration is active and that potentially new IP
> rejects or other security modifications now are active (if performed at the
> same opportunity) -- especially since users typically do not check the logs
> regularly if there is no problem they are aware of.
>
>
The documentation could maybe better describe what is considered successful
but these functions state they signal other, multiple, backends. Signaling
is unidirectional so practically speaking all the function knows is that it
successfully sent the signals, not that those signals were received and/or
successfully processed; information it doesn’t readily have.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2020-10-04 16:18:43 | BUG #16653: Regression in CTE evaluation |
Previous Message | PG Bug reporting form | 2020-10-03 19:32:58 | BUG #16652: SELECT pg_reload_conf(); returning true despite loading config has failed |