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.
