Re: A systematic way of handling Xapian lock errors?
authorMatt Armstrong <marmstrong@google.com>
Tue, 2 Aug 2016 22:46:39 +0000 (15:46 +1700)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 23:22:17 +0000 (16:22 -0700)
75/01a21c8b147ed361a13d65ef6dcc475ebef8a8 [new file with mode: 0644]

diff --git a/75/01a21c8b147ed361a13d65ef6dcc475ebef8a8 b/75/01a21c8b147ed361a13d65ef6dcc475ebef8a8
new file mode 100644 (file)
index 0000000..bf103a2
--- /dev/null
@@ -0,0 +1,99 @@
+Return-Path: <marmstrong@google.com>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id D2C5F6DE00BD\r
+ for <notmuch@notmuchmail.org>; Tue,  2 Aug 2016 15:46:52 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.909\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=0.113,\r
+  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
+ RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.211, SPF_PASS=-0.001,\r
+ T_RP_MATCHES_RCVD=-0.01] autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id xX8H2KOFSCh7 for <notmuch@notmuchmail.org>;\r
+ Tue,  2 Aug 2016 15:46:45 -0700 (PDT)\r
+Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com\r
+ [209.85.192.181])\r
+ by arlo.cworth.org (Postfix) with ESMTPS id 1CF3C6DE00B8\r
+ for <notmuch@notmuchmail.org>; Tue,  2 Aug 2016 15:46:45 -0700 (PDT)\r
+Received: by mail-pf0-f181.google.com with SMTP id y134so70485023pfg.0\r
+ for <notmuch@notmuchmail.org>; Tue, 02 Aug 2016 15:46:45 -0700 (PDT)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\r
+ s=20120113;\r
+ h=from:to:subject:in-reply-to:references:user-agent:date:message-id\r
+ :mime-version; bh=P8R4n9ZbHaQPC27j+h0mz8/Xw/+GoC+jqHw9Ww6NLnQ=;\r
+ b=Qwd8hNGfPS2XxL2J4pWMxDKPvl1YcDZHWUHo2dnyzukG4bJoWtMEO5PBbH6/Usxbs3\r
+ 5/poC2p9ieXypsDVAqKb1kdMkqZmgkUEU2su5/8yeVtyw6wU/OHm3wZ4yevA5iGIkIJ1\r
+ 9HPP15F18sBN3x42N2AsOP+0QAUyAfMGGlAQsAMw05odNl4dT2vcnKGVR1G2diTGgGlp\r
+ 6lUfERVTJ5zoGEAy4CuFqR/2WK1Yurz768xUIB2uBYJg8sKGxvc7eib/EnB2Hn8Y2gyW\r
+ TpS2Npt8kilNDiKb7bw5K4D9pWuzgvLjGNSvrFiy7lJMjhoqqZLM/h73kZcGnznsJA82 wbmQ==\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+ d=1e100.net; s=20130820;\r
+ h=x-gm-message-state:from:to:subject:in-reply-to:references\r
+ :user-agent:date:message-id:mime-version;\r
+ bh=P8R4n9ZbHaQPC27j+h0mz8/Xw/+GoC+jqHw9Ww6NLnQ=;\r
+ b=EzaSvwK6BcFJTaAAgd8sMABaJQxZ3dcVEeDeOBpYkNQVsxoajOvAAyK+hmKt/lHO4h\r
+ FrjFIHJ4faQbN3IoDyPg9+V7YgJrXsQFeQiHsmGvav8Yopb8w3n9wmemXsewMJmc13i+\r
+ iE4Xw+96GbTobJGIUern/BwUx2WJ9vbKcsTHpzWCS6S9ZTBYb0FBmsi5NwCCHmMxy/lJ\r
+ QYwtMCGmBsQqt/BHzQZBCoQFSMkdjBdk0SvE3v0zql69YD/7YvzxQkeZTMsVbKkuMUwf\r
+ MB7PdJennP2Dh+QkxU2G7Gd/3QHyxz2JAESbyIDGTskdlhOIB5FteznQwgGCRYBUs/5b\r
+ k67w==\r
+X-Gm-Message-State:\r
+ AEkoouukgSB2yXk8tntGnlIG1NDeirMwVV1oTypY72NtB1xzSUHls8wCWrXoR39F83jxR39R\r
+X-Received: by 10.98.192.12 with SMTP id x12mr109098438pff.54.1470178004310;\r
+ Tue, 02 Aug 2016 15:46:44 -0700 (PDT)\r
+Received: from marmstrong-linux.kir.corp.google.com\r
+ ([2620:0:1008:1101:419b:e62d:4938:a6b6])\r
+ by smtp.gmail.com with ESMTPSA id wp4sm7241540pab.15.2016.08.02.15.46.42\r
+ (version=TLS1_2 cipher=AES128-SHA bits=128/128);\r
+ Tue, 02 Aug 2016 15:46:43 -0700 (PDT)\r
+From: Matt Armstrong <marmstrong@google.com>\r
+To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org\r
+Subject: Re: A systematic way of handling Xapian lock errors?\r
+In-Reply-To: <87lh0evmk9.fsf@maritornes.cs.unb.ca>\r
+References: <qf5d1lrkx8s.fsf@marmstrong-linux.kir.corp.google.com>\r
+ <87lh0evmk9.fsf@maritornes.cs.unb.ca>\r
+User-Agent: Notmuch/0.21 (https://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Tue, 02 Aug 2016 15:46:39 -0700\r
+Message-ID: <qf5k2fykcvk.fsf@marmstrong-linux.kir.corp.google.com>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 02 Aug 2016 22:46:52 -0000\r
+\r
+David Bremner <david@tethera.net> writes:\r
+\r
+> Matt Armstrong <marmstrong@google.com> writes:\r
+>\r
+>\r
+>> To address both, has something like this ever been considered:\r
+>>\r
+>>   notmuch --lock_timeout <seconds> COMMAND ARG...\r
+>>\r
+>> Then frontends like Emacs could lean on retry logic written in C.  If\r
+>> this seems workable, it is something I can try implementing.\r
+>\r
+> notmuch in git master uses xapians lock retry if present (xapian\r
+> 1.3+). Currently there is no timeout, but Olly seemed receptive to the\r
+> idea of adding one, so I'd suggest that's the right place to work on\r
+> improving this. You may find that just having unbounded lock retries\r
+> (i.e. blocking opens) is enough for your issues.\r
+\r
+Ah great.  I am still on Xapian 1.2 by way of running a relatively old\r
+Linux distro.  Building a personal version of Xapian as we speak...\r