Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D498ADD24 for ; Mon, 24 Sep 2012 16:09:36 +0000 (UTC) Received: (qmail 38038 invoked by uid 500); 24 Sep 2012 16:09:35 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 37990 invoked by uid 500); 24 Sep 2012 16:09:35 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 37980 invoked by uid 99); 24 Sep 2012 16:09:35 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Sep 2012 16:09:35 +0000 Received: from localhost (HELO mail-vb0-f52.google.com) (127.0.0.1) (smtp-auth username rnewson, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Sep 2012 16:09:35 +0000 Received: by vbjk17 with SMTP id k17so5798752vbj.11 for ; Mon, 24 Sep 2012 09:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.13.33 with SMTP id e1mr7720969vec.51.1348502974022; Mon, 24 Sep 2012 09:09:34 -0700 (PDT) Received: by 10.52.90.69 with HTTP; Mon, 24 Sep 2012 09:09:33 -0700 (PDT) In-Reply-To: References: <1341622793.20120924143243@whiletrue.com> Date: Mon, 24 Sep 2012 17:09:33 +0100 Message-ID: Subject: Re: recovering data from an unfinished compaction db From: Robert Newson To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 That does imply that the last valid header is a long way back up the file, though. On 24 September 2012 17:00, Paul Davis wrote: > I'd ignore the snappy error for now. There's no way this thing ran for > an hour and then suddenly hit an error in that code. If this is like a > bug I've seen before the reason that this runs out of RAM is due to > the code that's searching for a header not releasing binary ref counts > as it should be. > > The quickest way to fix this would probably be to go back and update > recover-couchdb to recognize the new disk format. Although that gets > harder now that snappy compression is involved. > > On Mon, Sep 24, 2012 at 10:32 AM, Dave Cottlehuber wrote: >> On 24 September 2012 15:02, Robert Newson wrote: >>> {badmatch,{error,snappy_nif_not_loaded} makes me wonder if this 1.2 >>> installation is even right. >>> >>> Can someone enlighten me? Is it possible to get this error spuriously? >> >> No. I'd be keen to see a bit of logfiles to understand what's not working. >> >>> Does running out of RAM cause erlang to unload NIF's? >> >> I don't think so on Windows. >> >> There's an R15B01 based build here: >> https://www.dropbox.com/sh/jeifcxpbtpo78ak/GG9fjWOyDt/Snapshots/20120524 >> that has a fix for a more recent version of Windows server than I have >> to address one NIF loading error, although there are a number of >> possible causes. >> >> @Rudi can you give this a go & report back? >> >> A+ >> Dave