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: | 200707181212.03354.peter_e@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
http://developer.postgresql.org/~petere/
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-07-18 10:16:42 | SSPI authentication - patch |
Previous Message | Peter Eisentraut | 2007-07-18 06:27:16 | Re: execl() sentinel |