Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: delayed_commits false
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <4C33B24E.8050109@gmail.com>
Date: Wed, 7 Jul 2010 13:33:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <39130BF2-1000-4F7E-B01B-7564B9C34BDD@apache.org>
References: <4C31FF1A.30002@gmail.com>
 <FDFF9131-A857-48C1-A2E1-5DBD39323F66@apache.org>
 <4C33B24E.8050109@gmail.com>
To: dev@couchdb.apache.org


On 7 Jul 2010, at 00:46, Volker Mische wrote:

> On 07.07.2010 00:06, Damien Katz wrote:
>>=20
>> On Jul 5, 2010, at 8:49 AM, Volker Mische wrote:
>>=20
>>> Hi All,
>>>=20
>>> delayed_commits were enabled to have better performance especially =
for single writers. The price you pay for is that you potentially lose =
up to one second of writes in case of a crash.
>>>=20
>>> Such a setting makes sense, though in my opinion it shouldn't be =
enabled by default. I expect* that people running into performance =
issues at least take a look at the README or a FAQ section somewhere. =
There the delayed_commit setting could be pointed out.
>>>=20
>>> I'd like to be able to say that on a vanilla CouchDB it's hard to =
lose data, but I can't atm. I'm also well aware that there will be =
plenty of performance tests when 1.0 is released and people will =
complain (if delayed_commits would be set to false by default) that it =
is horrible slow. Though safety of the data is more important for me.
>>>=20
>>> If the only reason why delayed_commits is true by default are the =
performance tests of some noobs, I really don't think it's a price worth =
paying.
>>>=20
>>> *I know that in reality people don't
>>>=20
>>> I would like to see delayed_commits=3Dfalse for 1.0
>>=20
>> Last year we turned off delayed commits by default. We got lots of =
complaints, the performance impact was too great. So we switched it =
back. We aren't the first storage engine to go around on this. For =
example, Apple's core data switched to using full fsyncs for each write =
in 10.4, but then switched it back for 10.5:
>>=20
>> =
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Core=
Data/Articles/cdPersistentStores.html
>>=20
>> "Important: The default behaviors in Mac OS X v10.4 an 10.5 are =
different. In Mac OS X v10.4, SQLite uses FULL_FSYNC by default; in Mac =
OS X v10.5 it does not."
>>=20
>> Anyway, we can improve the documentation warning's, etc, but we =
should stay with the current defaults.
>>=20
>> -Damien
>>=20
>=20
> As 1.0 is approaching fast, I think this discussion is pretty =
important. Especially this thread showed that there are people that =
prefer setting delayed_commits to false. Although sometimes someone has =
to make the last call, and there is probably no one better than the =
creator of the project, I think it this case the decision should be made =
by more people.
>=20
> For *me personally* the authority of Apache CouchDB are the =
committers. I would love to see them vote on this topic (being it public =
or private doesn't matter).

(just clarifying procedure)

By Apache policy, every voice on dev@ needs to be considered. The final =
call for a release (the release vote) is up to the Project=92s =
Management Committee (PMC) which is Damien, Noah, J Chris, Christopher =
and myself.

Cheers
Jan
--=20