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 6C0B27F7206C9E4CA54AE035729E9C383BE8E6A7@szxeml509-mbx
Whole thread Raw
In response to Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Amit kapila <amit.kapila@huawei.com>)
List pgsql-hackers
On Saturday, November 24, 2012 10:56 PM Tom Lane wrote:
Amit kapila <amit.kapila@huawei.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.


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Doc patch: Document names of automatically created constraints and indexes
Next
From: Jeff Janes
Date:
Subject: Re: Use of fsync; was Re: Pg_upgrade speed for many tables