couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: [VOTE] Apache CouchDB 1.2.0 release, third round
Date Wed, 28 Mar 2012 20:32:36 GMT
Thanks!

On Wed, Mar 28, 2012 at 9:26 PM, Jan Lehnardt <jan@apache.org> wrote:

>
> On Mar 28, 2012, at 20:25 , Noah Slater wrote:
>
> > This vote has been aborted. Thank you to everyone who participated.
>
> Hey Noah,
>
> I applied Filipe's patch from COUCHDB-1451 and ran `make distcheck`
> and the browser tests and got all green.
>
> Since this doesn't affect 1.1.1, I don't think this should be noted in
> CHANGES or NEWS.
>
> I'd say the 1.2.x is readier than ever to go out :)
>
> Cheers
> Jan
> --
>
>
> >
> > On Wed, Mar 28, 2012 at 7:14 PM, Jan Lehnardt <jan@apache.org> wrote:
> >
> >>
> >> On Mar 28, 2012, at 20:07 , Filipe David Manana wrote:
> >>
> >>> On Wed, Mar 28, 2012 at 7:03 PM, Jan Lehnardt <jan@apache.org> wrote:
> >>>>
> >>>> On Mar 28, 2012, at 19:58 , Filipe David Manana wrote:
> >>>>
> >>>>> On Wed, Mar 28, 2012 at 6:51 PM, Stefan Kögl <koeglstefan@gmail.com>
> >> wrote:
> >>>>>> Hi everybody,
> >>>>>>
> >>>>>> I just wanted to raise some attention to the DB compaction bug
> >> discovered today
> >>>>>>
> >>>>>> https://issues.apache.org/jira/browse/COUCHDB-1451
> >>>>>>
> >>>>>> While I initially discovered the bug with a 1.1.2 instance,
this
> could
> >>>>>> also affect 1.2. I think this issue should be resolved before
> closing
> >>>>>> the vote. Filipe already provided a patch, so it shouldn't take
too
> >>>>>> long.
> >>>>>
> >>>>> Stefan, the patch is only for 1.2.x (and master).
> >>>>> That exact issue can't happen on 1.1.x releases, as it's related
to
> >>>>> code added in 1.2.x.
> >>>>>
> >>>>> I'm voting -1 on this round just because of this issue.
> >>>>
> >>>> Filipe, can you explain how frequent this issue would be? I can't
> quite
> >>>> discover the circumstances from the patch & commit message.
> >>>
> >>> Very frequent on some environments / work loads. It's highly timing
> >>> sensitive. Happens if the compactor inserts the last batch of btree
> >>> records in less than 500ms after the previous batch.
> >>
> >> That sounds common enough to me that we should avoid shipping this in
> 1.2.0
> >>
> >> Cheers
> >> Jan
> >> --
> >>
> >>
>
>

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