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

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Proposal for Allow postgresql.conf values to be changed via SQL
Дата
Msg-id 006a01cdbdc1$ef739680$ce5ac380$@kapila@huawei.com
обсуждение исходный текст
Ответ на Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Thursday, November 08, 2012 8:07 PM Alvaro Herrera wrote:
> Amit Kapila escribió:
>
> > 3. Two backends trying to write to .auto file
> >        we can use ".auto.lock" as the the lock by trying to create it
> in
> > exclusive mode as the first step
> >        of the command. If it already exists then backend needs to
> wait.
>
> So changing .auto settings would be nontransactional?

No, it should behave the way you explained below.
The points mentioned in above mail are just to explain the basic concept.

>The other way to
> define this would be to have a lock that you grab and keep until end of
> transaction, and the .auto.lock file is deleted if the transaction is
> aborted; so have the .auto.lock -> .auto rename only happen at
> transaction commit.

Is this behavior sane for Transaction block, as in transaction block some
other backend might need to wait
for little longer, if both issued a command to change config parameter?

IMO it is okay, as the usage of command to change config parameters inside a
transaction block would be less.


With Regards,
Amit Kapila.





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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Proposal for Allow postgresql.conf values to be changed via SQL