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
