Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
От | Amit Kapila |
---|---|
Тема | Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |
Дата | |
Msg-id | 002d01ce1ee0$cfb13d90$6f13b8b0$@kapila@huawei.com обсуждение исходный текст |
Ответ на | Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] (Greg Stark <stark@mit.edu>) |
Ответы |
Re: Proposal for Allow postgresql.conf values to be changed via
SQL [review]
|
Список | 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.
В списке pgsql-hackers по дате отправления: