On 2013-08-05 12:53:24 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2013-08-05 12:18:25 -0400, Bruce Momjian wrote: > >> I am unclear why we don't need a lock around _each_ GUC, i.e. if two > >> sessions try to modify the same GUC at the same time. And if we need a > >> lock, seems we can have just one and write all the settings to one file > >> --- it is not like we have trouble doing locking, though this is > >> cluster-wide locking. > > > If you have two sessions modifying the same variable, one is going to > > win and overwrite the other's setting with or without locking around > > GUCs unless you error out if somebody else holds the lock. > > The point of a lock is just to ensure that the end result is one valid > state or the other, and not something corrupt.
Sure. That's what I tried to explain. I've completely missed to mention in this mail why the safe rename dance is sufficient to guarantee a correct file with one-file-per-guc... > We would certainly need a > lock if we write to a single file. With file-per-GUC, we could possibly > dispense with a lock if we depend on atomic file rename(); though whether > it's wise to assume that for Windows is unclear. Afaik it should be safe on anything NT based via Replacefile. Anything else/earlier isn't supported anyways... I think there's already a custom rename() implementation on windows? Don't we already rely on atomic renames working for the control file? > (Note that we ought to > write a temp file and rename it into place anyway, to avoid possibly > corrupting the existing file on out-of-disk-space. The only thing that > needs discussion is whether to add an explicit lock around that.) Yes, agreed. All versions of the patch that I've read have done so luckily. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
