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