From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 1D2FB6DE1747 for ; Fri, 24 Feb 2017 03:40:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.005 X-Spam-Level: X-Spam-Status: No, score=-0.005 tagged_above=-999 required=5 tests=[AWL=0.006, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6sKYZKNOYt1 for ; Fri, 24 Feb 2017 03:40:06 -0800 (PST) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id D559F6DE16B9 for ; Fri, 24 Feb 2017 03:40:05 -0800 (PST) Received: from remotemail by fethera.tethera.net with local (Exim 4.84_2) (envelope-from ) id 1chEDc-0004iq-Su; Fri, 24 Feb 2017 06:39:24 -0500 Received: (nullmailer pid 19898 invoked by uid 1000); Fri, 24 Feb 2017 11:40:00 -0000 From: David Bremner To: Gaute Hope , notmuch@notmuchmail.org Subject: Re: [RFC patch 2/2] lib: handle DatabaseModifiedError in _n_message_ensure_metadata In-Reply-To: <1487931600.gabu6r3kvx.astroid@strange.none> References: <87y3wx2k3s.fsf@tethera.net> <20170224020048.10718-1-david@tethera.net> <20170224020048.10718-2-david@tethera.net> <87efyo2ti9.fsf@tethera.net> <1487931600.gabu6r3kvx.astroid@strange.none> Date: Fri, 24 Feb 2017 07:40:00 -0400 Message-ID: <87zihb24xb.fsf@tethera.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.22 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: Fri, 24 Feb 2017 11:40:07 -0000 Gaute Hope writes: > David Bremner writes on februar 24, 2017 3:49: >> David Bremner writes: >> >>> The error handling here still needs work. The retry count should be >>> handled in more sane way, and both running out of retries and an error >>> return from notmuch_database_reopen should be handled. >> >> Probably the number of retries can be limited to 1, since afaict, reopen >> is not going to return any recoverable errors. > > Does _reopen block if the db is locked? It's not documented to block or throw an exception in that case. It's only applicable to read-only databases, so the lack of blocking makes sense. d