| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |
| Date: | 2013-03-11 19:19:32 |
| Message-ID: | CAM-w4HP5ER4vUEJAdtwf7=T86FvwhohiG1DbuvHbT4ougpjfOQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Mar 11, 2013 at 7:39 AM, Greg Smith <greg(at)2ndquadrant(dot)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.
I can see you're right about surprising users but is there not another
way to solve the same problem without making that impossible?
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-03-11 19:30:01 | Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables) |
| Previous Message | Greg Stark | 2013-03-11 19:13:10 | Re: Using indexes for partial index builds |