couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: delayed_commits false
Date Wed, 07 Jul 2010 11:33:53 GMT

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

> On 07.07.2010 00:06, Damien Katz wrote:
>> On Jul 5, 2010, at 8:49 AM, Volker Mische wrote:
>>> Hi All,
>>> 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.
>>> 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.
>>> 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.
>>> 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.
>>> *I know that in reality people don't
>>> I would like to see delayed_commits=false for 1.0
>> 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:
>> "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."
>> Anyway, we can improve the documentation warning's, etc, but we should stay with
the current defaults.
>> -Damien
> 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.
> 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’s Management Committee (PMC) which is Damien, Noah,
J Chris, Christopher and myself.


View raw message