Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Date
Msg-id CAM-w4HP5ER4vUEJAdtwf7=T86FvwhohiG1DbuvHbT4ougpjfOQ@mail.gmail.com
Whole thread Raw
In response to Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Craig Ringer <craig@2ndquadrant.com>)
Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Amit Kapila <amit.kapila@huawei.com>)
Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
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.

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



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Using indexes for partial index builds
Next
From: Tom Lane
Date:
Subject: Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables)