Skip site navigation (1) Skip section navigation (2)

Re: Async Commit, v21 (now: v22)

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-patches(at)postgresql(dot)org
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>,"Bruce Momjian" <bruce(at)momjian(dot)us>
Subject: Re: Async Commit, v21 (now: v22)
Date: 2007-07-18 10:12:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
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.

Peter Eisentraut

In response to


pgsql-patches by date

Next:From: Magnus HaganderDate: 2007-07-18 10:16:42
Subject: SSPI authentication - patch
Previous:From: Peter EisentrautDate: 2007-07-18 06:27:16
Subject: Re: execl() sentinel

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group