Re: Proposal for Allow postgresql.conf values to be changed via SQL
Amit Kapila <amit.kapila@huawei.com>
From: Amit Kapila <amit.kapila@huawei.com>
To: "'Alvaro Herrera'" <alvherre@2ndquadrant.com>
Cc: "'Robert Haas'" <robertmhaas@gmail.com>, "'Josh Berkus'" <josh@agliodbs.com>, "'Tom Lane'" <tgl@sss.pgh.pa.us>, "'Magnus Hagander'" <magnus@hagander.net>, "'Christopher Browne'" <cbbrowne@gmail.com>, "'PostgreSQL-development'" <pgsql-hackers@postgresql.org>
Date: 2012-11-08T15:01:29Z
Lists: 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.