Re: Async Commit, v21 (now: v22) - Mailing list pgsql-patches

From Florian Weimer
Subject Re: Async Commit, v21 (now: v22)
Date
Msg-id 82k5sqkww8.fsf@mid.bfk.de
Whole thread Raw
In response to Re: Async Commit, v21 (now: v22)  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: Async Commit, v21 (now: v22)  ("Simon Riggs" <simon@2ndquadrant.com>)
Re: Async Commit, v21 (now: v22)  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-patches
+    <para>
+     Asynchronous commit provides different behaviour to setting
+     <varname>fsync</varname> = off, which is a server-wide
+     setting that will alter the behaviour of all transactions,
+     overriding the setting of <varname>synchronous_commit</varname>,
+     as well as risking much wider data loss.  With <varname>fsync</varname>
+     = off the WAL written but not fsynced, so data is lost only in case
+     of a system crash. Both WAL and datafiles written within the last
+     few seconds would be at risk, affecting all types of database
+     transactions. The precise number depends upon whether your operating
+     system is configured for automatic filesystem writeback and what the
+     delay is set too; Linux currently defaults to 30 seconds.  With
+     asynchronous commit the WAL is not written to disk at all at commit
+     time, so data is lost if there is a database server crash, whether or
+     not the system crashes at the same time.
+    </para>

I think fsync=off also endagers metadata, while synchronous_commit=off
should be perfectly safe as far as the metadata is concerned.
Wouldn't this be worth mentioning as well?


--
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

pgsql-patches by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Async Commit, v21 (now: v22)
Next
From: "Simon Riggs"
Date:
Subject: Re: Async Commit, v21 (now: v22)