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-25 05:01:12
Message-ID: 6C0B27F7206C9E4CA54AE035729E9C383BE8E6A7@szxeml509-mbx
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2012-11-25 05:42:08 Re: Use of fsync; was Re: Pg_upgrade speed for many tables
Previous Message Peter Eisentraut 2012-11-24 23:02:41 Re: Doc patch: Document names of automatically created constraints and indexes