Re: BUG #16652: SELECT pg_reload_conf(); returning true despite loading config has failed

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.

In response to

Browse pgsql-bugs by date

  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