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

From: Amit kapila <amit(dot)kapila(at)huawei(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, "cedric(at)2ndquadrant(dot)com" <cedric(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date: 2012-11-28 14:47:44
Message-ID: 6C0B27F7206C9E4CA54AE035729E9C383BE9AA54@szxeml509-mbx
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sunday, November 25, 2012 10:31 AM Amit kapila wrote:
On Saturday, November 24, 2012 10:56 PM Tom Lane wrote:
Amit kapila <amit(dot)kapila(at)huawei(dot)com> writes:
> On Friday, November 23, 2012 10:10 PM Fujii Masao wrote:
>>>> What happens if the server crashes while SET PERSISTENT is writing the
>>>> setting to the file? A partial write occurs and restart of the server would fail
>>>> because of corrupted postgresql.auto.conf?

>>> This situation will not happen as SET PERSISTENT command will first write to ".lock" file and then at commit time,
>>> rename it to ".auto.conf".

>>Yes, the right way to write the config file is to write under a
>>temporary name, fsync the file, and then use rename(2) to atomically
>>move it into place. However, the above is contemplating some extra
>>complexity that I think is useless and undesirable, namely postponing
>>the rename until commit time. The point of the suggestion that SET
>>PERSISTENT not be allowed inside a transaction block is so that you can
>>write the file immediately rather than have to add commit-time mechanism
>>to support the feature.

>Sure, I will update the code such that it should write the file immediately.
>However for error cases, the temporary file will be deleted at abort time only rather than by using TRY..CATCH.

The updated Patch with this mail contains following updation:

1. Fixed all problems reported.
2. Added syntax for the following.
1. Reset persistent config_parameter.
2. Reset persistent all
3. Modified the functionality of set default as get the default value for the configuration and convert into units (sec, MB and etc)
and add/rewrite configuration parameter in the postgresql.auto.conf.
4. Added the tests to the regression suite.
5. PERSISTENT Keyword is added to the reserved keyword list. As it was giving some errors given below while parsing gram.y
15 shift/reduce conflicts .
6. During set persistent command if the postgresql.auto.conf file not exists, then it creates the file and gives
a NOTICE message to user.
7. During restart of internal processes because of any backend crash time, if any .lock file presents, it will be deleted.
8. Gives a warning message to user, if the postgresql.auto.conf file is not present in postgresql.conf file.

With Regards,
Amit Kapila.

Attachment Content-Type Size
set_persistent_v2.patch application/octet-stream 83.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-11-28 14:51:18 Re: Review: Extra Daemons / bgworker
Previous Message Andres Freund 2012-11-28 14:38:40 Re: PITR potentially broken in 9.2