Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
От | Boszormenyi Zoltan |
---|---|
Тема | Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |
Дата | |
Msg-id | 5119011D.90804@cybertec.at обсуждение исходный текст |
Ответ на | Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Re: Proposal for Allow postgresql.conf values to be
changed via SQL [review]
|
Список | pgsql-hackers |
2013-02-11 15:25 keltezéssel, Andres Freund írta: > On 2013-02-11 15:21:13 +0100, Boszormenyi Zoltan wrote: >> 2013-01-24 18:02 keltezéssel, Tom Lane írta: >>> Andres Freund <andres@2ndquadrant.com> writes: >>>> On 2013-01-24 11:22:52 -0500, Tom Lane wrote: >>>>> Say again? Surely the temp file is being written by whichever backend >>>>> is executing SET PERSISTENT, and there could be more than one. >>>> Sure, but the patch acquires SetPersistentLock exlusively beforehand >>>> which seems fine to me. >>> Why should we have such a lock? Seems like that will probably introduce >>> as many problems as it fixes. Deadlock risk, blockages, etc. It is not >>> necessary for atomicity, since rename() would be atomic already. >> There is a problem when running SET PERSISTENT for different GUCs >> in parallel. All happen to read the same original file, and only one >> setting ends up in the result if you rely only on the rename() being atomic. >> The LWLock provides the serialization for that problem. > Tom was voting for one-setting-per-file, in that case the problem > doesn't exist. I voted for the one-file approach and was arguing from the POV of the current implementation. -- ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/
В списке pgsql-hackers по дате отправления: