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-w4HPodXZ=i-C70kPh4ExC2oTKN_-U4uZnj=SiphZee43t3w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Greg Smith <greg@2ndQuadrant.com>)
Ответы Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Mar 12, 2013 at 9:06 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> That's jumping right over a few rounds of simpler ways to do this, and just
> going right to the approach we know allows adding more such options later
> with minimal grammar impact.

As Craig intimated, the minimal grammar impact would be simply

BEGIN;
set persistent maintenance_work_mem='2GB';
set persistent work_mem='2GB';
COMMIT;

Sending the sighup at transaction end seems like a fairly safe thing
to do too. It's hard to imagine it failing and if it did the worst
case would be that other backends would still have the old values too.

To be honest I went through the gucs last night looking for a better
example than this and didn't really find any compelling examples. The
best I could come up with was adjusting several query costs in tandem.
Hardly the end of the world if it didn't work. The worst case would be
some security sensitive option alongside a second parameter for
limiting its scope, but I couldn't find any such examples in a quick
search. (And that's probably a good thing)

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Fix document typo
Следующее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.3] OAT_POST_ALTER object access hooks