Le vendredi 16 novembre 2012 15:08:30, Amit Kapila a écrit :
> On Thursday, November 15, 2012 8:18 PM Amit kapila wrote:
> > On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote:
> > On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila <amit(dot)kapila(at)huawei(dot)com>
> > 
> > wrote:
> > > 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.
> > 
> > Attached patch contains implementaion for above concept.
> > It can be changed to adapt the write file based on GUC variables as
> > described by me yesterday or in some other better way.
> > 
> > Currenty to remember and forget, I have used below concept:
> > 1. Read postgresql.auto.conf in memory.
> > 2. parse the GUC_file for exact loction of changed variable 3. update
> > the changed variable in memory at location found in step-2 4. Write the
> > postgresql.auto.conf
> > 
> > Overall changes:
> > 1. include dir in postgresql.conf at time of initdb 2. new built-in
> > function pg_change_conf to change configuration settings 3. write file
> > as per logic described above.
> > 
> > Some more things left are:
> > 1. Transactional capability to command, so that rename of .lock file to
> > .auto.conf can be done at commit time.
> 
> About transaction capability, I think it will be difficult to implement it
> in transaction block,
> because during Rollback to savepoint it is difficult to rollback (delete
> the file), as there is no track of changes w.r.t
> Savepoint.

not a problem.
consider that pseudo code:

begin serializable;

update pg_settings; -- or whatever the name of the object (can include 
creation of a table, etc...)

savepoint...

update pg_settings;

rollback to savepoint;

commit;  <-- here the deferred trigger FOR STATEMENT on pg_settings is fired 
and is responsible to write/mv the/a file.

Is there something obvious I'm not seeing ?


-- 
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

In response to

• Re: Proposal for Allow postgresql.conf values to be changed via SQL at 2012-11-16 14:08:30 from Amit Kapila

Responses

• Re: Proposal for Allow postgresql.conf values to be changed via SQL at 2012-11-17 13:25:34 from Amit Kapila
• Re: Proposal for Allow postgresql.conf values to be changed via SQL at 2012-11-17 21:38:03 from Fujii Masao

pgsql-hackers by date

Next:	From: Merlin Moncure	Date: 2012-11-16 14:26:06
	Subject: Re: WIP patch for hint bit i/o mitigation
Previous:	From: Andres Freund	Date: 2012-11-16 14:14:32
	Subject: Re: logical changeset generation v3 - comparison to Postgres-R change set format