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? I don't see this ever becoming a realistic concern for concurrency and performance, and the shm cost would be tiny. -- Craig Ringer 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
