+    <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                <[EMAIL PROTECTED]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra├če 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to