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

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Дата
Msg-id CAM-w4HP5ER4vUEJAdtwf7=T86FvwhohiG1DbuvHbT4ougpjfOQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Josh Berkus <josh@agliodbs.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Using indexes for partial index builds
Следующее
От: Tom Lane
Дата:
Сообщение: Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables)