I think there is a balance that we can find here between user experience and durability.
I think the biggest question for me is, who is the primary target of the tarball download? If it's developers, I think we should leave it on. If it's people who are going to put it up, vanilla, in to production, we should turn them off. I know that I would certainly advocate keeping them off in the CouchDBX build. -Mikeal On Tue, Jul 6, 2010 at 3:46 PM, Volker Mische <[email protected]>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: >> >> >> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html >> >> "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). > > Cheers, > Volker >
