Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

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