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

From Amit kapila
Subject Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date
Msg-id 6C0B27F7206C9E4CA54AE035729E9C3828548855@szxeml509-mbx
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  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
On Thursday, November 08, 2012 7:56 PM Amit Kapila
On Thursday, November 08, 2012 1:45 AM Robert Haas wrote:
> On Wed, Nov 7, 2012 at 2:50 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> >> Well, Magnus' proposed implementation supposed that the existing
>> values
>> >> *have* been loaded into the current session.  I agree that with some
>> >> locking and yet more code you could implement it without that.  But
> this
>> >> still doesn't seem to offer any detectable benefit over value-per-
> file.
> >
>> > Well, value-per-file is ugly (imagine you've set 40 different
> variables
>> > that way) but dodges a lot of complicated issues.  And I suppose
> "ugly"
> >> doesn't matter, because the whole idea of the auto-generated files is
> > >that users aren't supposed to look at them anyway.
>
>> That's pretty much how I feel about it, too.  I think value-per-file
> >is an ugly wimp-out that shouldn't really be necessary to solve this
>> problem.  It can't be that hard to rewrite a file where every like is
>> of the form:
>
>> key = 'value'

> I also believe that it should be possible to rewrite a file without loading
> values into the current session.
> One of the solution if we assume that file is of fixed format and each
> record (key = 'value') of fixed length can be:

> 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.
> 2. To handle locking issues, we can follow an approach similar to what "GIT"
> is doing for editing conf files (using .lock file):
>   a. copy the latest content of .auto to .auto.lock
>   b. make all the changes to auto.lock file.
>   c. at the end of command rename the auto.lock file to .auto file
>   d. otherwise if SQL COMMAND/function failed in-between we can delete the
> ".auto.lock" file
>3. Two backends trying to write to .auto file
>       we can use ".auto.lock" as the the lock by trying to create it in
>exclusive mode as the first step
>       of the command. If it already exists then backend needs to wait.

Please let me know if there are any objections or problems in above method of implementation,
else I can go ahead to prepare the patch for the coming CF.

For initial version I will use the function as syntax to provide this feature.

With Regards,
Amit Kapila.


pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Further pg_upgrade analysis for many tables
Next
From: Chen Huajun
Date:
Subject: Re: Fix errcontext() function