From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 5B554431FC2 for ; Tue, 15 Jul 2014 07:11:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9ZxG4jOnBZK for ; Tue, 15 Jul 2014 07:11:02 -0700 (PDT) Received: from yantan.tethera.net (yantan.tethera.net [199.188.72.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 5F4EA431FBD for ; Tue, 15 Jul 2014 07:11:02 -0700 (PDT) Received: from remotemail by yantan.tethera.net with local (Exim 4.80) (envelope-from ) id 1X73RX-0000zV-2u; Tue, 15 Jul 2014 11:10:55 -0300 Received: (nullmailer pid 19961 invoked by uid 1000); Tue, 15 Jul 2014 14:10:51 -0000 From: David Bremner To: Mark Walters , notmuch@notmuchmail.org Subject: Re: [PATCH] dump: make dump take Xapian write lock In-Reply-To: <1403554349-8888-1-git-send-email-markwalters1009@gmail.com> References: <87zjhh67e7.fsf@qmul.ac.uk> <1403554349-8888-1-git-send-email-markwalters1009@gmail.com> User-Agent: Notmuch/0.18.1+37~gde262a2 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Tue, 15 Jul 2014 11:10:51 -0300 Message-ID: <87y4vuaf10.fsf@maritornes.cs.unb.ca> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:11:09 -0000 Mark Walters writes: > > Discussion with Olly on irc indicates that this is currently the best > solution: in xapian trunk there may be better possibilities using > snapshots but they need to make it to a release and propogate out to > users before we can switch approach. I agree that this seems to be the only feasible approach to make dump atomic. I'm a little unsure about the benefits to the end user though. Currently, the user has to check the return code of dump to ensure it completed correctly. With this change, the user will still have to check that dump did not error out when trying to acquire a write lock. The following ticket http://trac.xapian.org/ticket/275 suggests that if we wanted to a blocking open, we'd be on our own. Did I miss something here about the benefits? I agree that failing earlier is nicer, but is that it? d