Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

Amit Kapila <amit.kapila@huawei.com>

From: Amit Kapila <amit.kapila@huawei.com>
To: "'Greg Stark'" <stark@mit.edu>, "'Greg Smith'" <greg@2ndquadrant.com>
Cc: "'Andres Freund'" <andres@2ndquadrant.com>, "'Boszormenyi Zoltan'" <zb@cybertec.at>, <pgsql-hackers@postgresql.org>
Date: 2013-03-12T05:16:53Z
Lists: pgsql-hackers
> From: gsstark@gmail.com [mailto:gsstark@gmail.com] On Behalf Of Greg
> Stark
> Sent: Tuesday, March 12, 2013 12:50 AM
> To: Greg Smith
> Cc: Amit Kapila; Andres Freund; Boszormenyi Zoltan; pgsql-
> hackers@postgresql.org
> Subject: Re: Re: Proposal for Allow postgresql.conf values to be
> changed via SQL [review]
> 
> On Mon, Mar 11, 2013 at 7:39 AM, Greg Smith <greg@2ndquadrant.com>
> wrote:
> 
> > I wasn't complaining that the change isn't instant.  I understand
> that can't
> > be done.  But I think the signal to reload should be sent.  If people
> > execute SET PERSISTENT, and it doesn't actually do anything until the
> server
> > is next restarted, they will be very surprised.  It's OK if it
> doesn't do
> > anything for a second, or until new sessions connect, because that's
> just
> > how SIGHUP/session variables work.  That's a documentation issue.
> Not
> > reloading the config at all, I think that's going to trigger a ton of
> future
> > support problems.
> 
> Think also about the case where someone wants to change multiple
> values together and having just some set and not others would be
> inconsistent.

Do you mean to say that because some variables can only be set after restart
can lead to 
inconsistency, or is it because of asynchronous nature of pg_reload_conf()?

> I can see you're right about surprising users but is there not another
> way to solve the same problem without making that impossible?


With Regards,
Amit Kapila.