+ 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.
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