On Monday, March 04, 2013 9:41 AM Craig Ringer wrote: > On 03/04/2013 09:07 AM, Greg Smith wrote: > > I'm not sure why you are opening the old auto config file with > > ParseConfigFp. Can't you just navigate the existing GUCs in memory > > and directly write the new one out? If someone is going to manually > > edit this file and use SET PERSISTENT, they're going to end up in > > trouble regardless. I don't think it's really worth the extra > > complexity needed to try and handle that case. > Additionally, if you want to avoid silently overwriting user changes, > you could store a timestamp for when we last updated the persistent > config and compare it to the on-disk timestamp before writing. If they > don't match a warning would be issued and the config would be > overwritten anyway. There's a race, of course, but since the worst case > is that we fail to issue a warning it's a pretty harmless one.
> As for the per-file vs single-file issue and concerns about locking > complexity: Can't we just use a global lock in shm to enforce that > exactly one backend at a time may be modifying the global > configuration? Yes, this is currently used. > I don't see this ever becoming a realistic concern for concurrency and > performance, and the shm cost would be tiny. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
