On 11/15/2012 11:38 PM, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Thu, Nov 15, 2012 at 6:53 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>>> The only thing you couldn't handle that way are SIGHUP settings, but the
>>> often-cited use cases work_mem, logging, etc. would work.
>> How hard would it be to make it work for SIGHUP?
> One issue is that pg_db_role_setting is currently considered only at
> session start, and unless you want to hack that somehow, these new
> settings would only be absorbed by freshly-started sessions.
>
> Now, there's already a good deal of asynchrony in when individual
> processes notice postgresql.conf updates, whether they're for SIGHUP
> or lesser settings. So maybe that's all right. If you weren't happy
> about it, one of several things you'd have to work out is how to send a
> SIGHUP only after you've committed the changes.
>
> Another and probably bigger thing is that SIGHUP is used for settings
> that do something useful only in background processes (eg checkpointer).
> Some of those processes are not capable of reading system catalogs at
> all. This is particularly a showstopper for settings affecting the
> postmaster itself, which is most certainly *not* going to grow the
> ability to read catalogs.
>
> On the whole I suspect the existing push towards rewritable config file
> entries is going to go further in less time for anything whose effects
> aren't limited to regular backend sessions. I don't object to Peter's
> idea as such, but it's not going to help us for SIGHUP settings.
>
> regards, tom lane
>
Why not just make the sending SIGHUP a separate command as it is now ?
SELECT pg_reload_config();
Hannu
