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

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Robert Haas'" <robertmhaas(at)gmail(dot)com>
Cc: "'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>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date: 2012-11-16 14:08:30
Message-ID: 00be01cdc403$dbe33920$93a9ab60$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

So to handle, we can do one of the following:
1. Handle it at command level only
2. Don't allow this command in transaction blocks
3. Rollback to Savepoint will have no effect w.r.t this command, only when
top transaction commits/rollback,
It commit/rollback the file.

IMO, option-2 is better.

Suggestions/Comments?

With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-11-16 14:11:07 Re: tuplesort memory usage: grow_memtuples
Previous Message Andres Freund 2012-11-16 14:05:32 Re: logical changeset generation v3 - comparison to Postgres-R change set format