On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila <amit.kap...@huawei.com> wrote: > Is the above opinion about only locking or even on a way to write the changed > things in a file as mentioned in point-1 in mail chain upthread. > (Point-1: > 1. While writing .auto file, it will always assume that .auto > file contain >> all config parameters. >> Now as this .auto file is of fixed format and fixed record size, it can >> directly write a given record to its particular position.) > What my thinking was that if we can decide that the format and size of each > configuration is fixed, it can be directly written without doing anything for > it in memory.
Uh, no, I don't think that's a good idea. IMHO, what we should do is: 1. Read postgresql.conf.auto and remember all the settings we saw. If we see something funky like an include directive, barf. 2. Forget the value we remembered for the particular setting being changed. Instead, remember the user-supplied new value for that parameter. 3. Write a new postgresql.conf.auto based on the information remembered in steps 1 and 2. Of course, if we go with one-file-per-setting, then this becomes even simpler: just clobber the file for the single setting being updated - creating it if it exists - and ignore all the rest. I don't personally favor that approach because I think I think it's clunky to manage, but YMMV. With either approach, it's worth noting that a RESET variant of this could be useful - which would either remove the chosen setting from postgresql.conf.auto, or remove the file containing the automatically-set value for that setting. I think my personal favorite syntax is: ALTER SYSTEM .. SET wunk = 'thunk'; ALTER SYSTEM .. RESET wunk; But I'm OK with something else if there's consensus. I don't particularly like SET PERSISTENT because I think this is more like ALTER DATABASE .. SET than it is like SET LOCAL, but IJWH. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers