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

From Simon Riggs
Subject Re: Async Commit, v21 (now: v22)
Date
Msg-id 1184944527.4428.2.camel@ebony.site
Whole thread Raw
In response to Re: Async Commit, v21 (now: v22)  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Async Commit, v21 (now: v22)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
On Wed, 2007-07-18 at 12:12 +0200, Peter Eisentraut wrote:
> Am Dienstag, 17. Juli 2007 20:31 schrieb Simon Riggs:
> > Here's the latest version. I've reviewed this to check that this does
> > what I want it to do, re-written various comments and changed a few
> > minor points in the code.
> >
> > I've also added a chunk to transam/README that describes the workings of
> > the patch from a high level.
> >
> > Now ready for final review.
>
> I'm not sure the following explanation is all that clear:
>
> +    <para>
> +     Asynchronous commit provides different behaviour to setting
> +     <varname>fsync</varname> = off, since that 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. With asynchronous commit the WAL is not written
> +       to disk at all by the user, so data is lost if there is a database
> +       server crash, as well as when the system crashes.
> +    </para>
>
> On the one hand, it claims that fsync off has much wider data loss
> implications than asynchronous commit, on the other hand, it states that the
> risk of a loss due to asynchronous commit happening is larger than fsync off.
> I *think* I know what this is trying to say, but I suspect that the average
> user might not be able to make a good choice of settings.

Thanks for reading. Updated version in new patch.

--
  Simon Riggs
  EnterpriseDB  http://www.enterprisedb.com


pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: configure.in / xml / quoting trouble
Next
From: Magnus Hagander
Date:
Subject: Re: SSPI authentication - patch