Skip site navigation (1) Skip section navigation (2)

Re: another idea for changing global configuration settings from SQL

From: Hannu Krosing <hannu(at)krosing(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: another idea for changing global configuration settings from SQL
Date: 2012-11-16 14:27:07
Message-ID: 50A64D3B.6050805@krosing.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On 11/15/2012 11:38 PM, Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Thu, Nov 15, 2012 at 6:53 PM, Peter Eisentraut <peter_e(at)gmx(dot)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



In response to

Responses

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2012-11-16 14:43:12
Subject: Re: Do we need so many hint bits?
Previous:From: Merlin MoncureDate: 2012-11-16 14:26:06
Subject: Re: WIP patch for hint bit i/o mitigation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group