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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
