+1 on delaying a decision on this until after 1.0, it's a big change and if we do make it we should let it sit in trunk and steep for a while.
But, JIRA is a terrible place to have a discussion so I'd rather we continue to use the mailing list. -Mikeal On Tue, Jul 6, 2010 at 4:03 PM, Damien Katz <[email protected]> wrote: > 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 > >>> > >> > > > >
