This issue has been discussed already. A change this big right before a 1.0 release is a very bad idea. If we decided to change it, we'd need to wait a good amount of time to understand how it affects downstream projects that take the defaults.
Here is a bug report that talks about it. There is more discussion in the mailing list as well. https://issues.apache.org/jira/browse/COUCHDB-449 -Damien On Jul 6, 2010, at 3:58 PM, Volker Mische wrote: > I have to admit that the point, that the main audience of a tarball are > developers is a good one. Perhaps people that do binary distributions of > CouchDB (like all the linux distros) could be encouraged to turn it to false > (though I have no idea what their general policy about changing defaults is). > > Cheers, > Volker > > On 07.07.2010 00:52, Mikeal Rogers wrote: >> 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 >>> >> >
