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

From: Cédric Villemain <cedric(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Amit kapila <amit(dot)kapila(at)huawei(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Christopher Browne <cbbrowne(at)gmail(dot)com>
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date: 2012-11-15 17:58:06
Message-ID: 201211151858.12878.cedric@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(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.
>
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-11-15 18:04:18 Re: another idea for changing global configuration settings from SQL
Previous Message Kohei KaiGai 2012-11-15 17:53:46 Re: [v9.3] writable foreign tables