Re: Async Commit, v21 (now: v22)
От | Simon Riggs |
---|---|
Тема | Re: Async Commit, v21 (now: v22) |
Дата | |
Msg-id | 1184944527.4428.2.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: Async Commit, v21 (now: v22) (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Async Commit, v21 (now: v22)
|
Список | 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 по дате отправления: