On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila <amit.kapila@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-1in 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
directlywritten 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