Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
От | Andres Freund |
---|---|
Тема | Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |
Дата | |
Msg-id | 20130313131340.GB27988@alap2.anarazel.de обсуждение исходный текст |
Ответ на | 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]
|
Список | pgsql-hackers |
On 2013-03-13 18:38:12 +0530, Amit Kapila wrote: > On Wednesday, March 13, 2013 6:10 PM Andres Freund wrote: > > On 2013-03-12 10:46:53 +0530, Amit Kapila wrote: > > > 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()? > > > > As long as SET PERSISTENT cannot be executed inside a transaction - or > > only takes effect after its end - there doesn't seem to be any problem > > executing ProcessConfigFile() directly. > > Do you mean to say we call directly ProcessConfigFile() at end of SET > PERSISTENT instead > Of pg_reload_conf() but in that case would it load the variables for other > backends? I'd say do both. Yes, we would evaluate config potentially twice. Who cares. Messages inside non-postmaster environments are only output at DEBUG2 anyway. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: