couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <mikeal.rog...@gmail.com>
Subject Re: delayed_commits false
Date Tue, 06 Jul 2010 23:07:24 GMT
+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 <damien@apache.org> 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<volker.mische@gmail.com
> >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
> >>>
> >>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message