On Tue, 2007-07-24 at 10:51 +0200, Florian Weimer wrote:
> + <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?
Well, I think "wider data loss" covers it for me, but I don't have a
problem with people wanting to detail the various problems that can
occur.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
