Re: Async Commit, v21 (now: v22) - Mailing list pgsql-patches

From Simon Riggs
Subject Re: Async Commit, v21 (now: v22)
Date
Msg-id 1185270243.4261.6.camel@ebony.site
Whole thread Raw
In response to Re: Async Commit, v21 (now: v22)  (Florian Weimer <fweimer@bfk.de>)
Responses Re: Async Commit, v21 (now: v22)  (Florian Weimer <fweimer@bfk.de>)
List pgsql-patches
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


pgsql-patches by date:

Previous
From: Florian Weimer
Date:
Subject: Re: Async Commit, v21 (now: v22)
Next
From: Florian Weimer
Date:
Subject: Re: Async Commit, v21 (now: v22)