Re: Proposal for Allow postgresql.conf values to be changed via SQL - Mailing list pgsql-hackers

From Cédric Villemain
Subject Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date
Msg-id 201211151858.12878.cedric@2ndquadrant.com
Whole thread Raw
In response to Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Amit kapila <amit.kapila@huawei.com>)
Responses Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Amit Kapila <amit.kapila@huawei.com>)
List pgsql-hackers
Le jeudi 15 novembre 2012 15:48:14, Amit kapila a écrit :
> On Wednesday, November 14, 2012 12:24 AM Robert Haas wrote:
>
> On Mon, Nov 12, 2012 at 10:59 PM, Amit kapila <amit.kapila@huawei.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.
>
> I am planing to upload the attached for this CF.
>
> Suggestions/Comments?

Yes, sorry to jump here so late.
* Why don't we use pg_settings ? (i.e. why not materialize the view and use
it, it should be easier to have something transactional and also serializable
with probably a DEFERRABLE select pg_reload_config() which mv the configuration
file at commit time)
* Can I define automatic parameters to be loaded before and/or after the non-
automatic parameters in a convenient way (without editing files at all)?

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

pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: [v9.3] writable foreign tables
Next
From: Robert Haas
Date:
Subject: Re: another idea for changing global configuration settings from SQL