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.
In response to
pgsql-hackers by date
|Next:||From: Jeff Janes||Date: 2012-11-25 05:42:08|
|Subject: Re: Use of fsync; was Re: Pg_upgrade speed for many tables|
|Previous:||From: Peter Eisentraut||Date: 2012-11-24 23:02:41|
|Subject: Re: Doc patch: Document names of automatically created
constraints and indexes|