c6/db16a7d437533ee9b0332324ad388898673196

   1 Return-Path: <SRS0=W5ue=IT=riseup.net=micah@srs.perfora.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id E2616431FBC\r
   6         for <notmuch@notmuchmail.org>; Sat,  2 Jan 2010 10:16:05 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id sevJSVleuIhe for <notmuch@notmuchmail.org>;\r
  11         Sat,  2 Jan 2010 10:16:05 -0800 (PST)\r
  12 Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])\r
  13         by olra.theworths.org (Postfix) with ESMTP id 2F89F431FAE\r
  14         for <notmuch@notmuchmail.org>; Sat,  2 Jan 2010 10:16:05 -0800 (PST)\r
  15 Received-SPF: pass (mxus2: domain of riseup.net designates 204.13.164.18 as\r
  16         permitted sender) client-ip=204.13.164.18;\r
  17         envelope-from=micah@riseup.net; helo=mx1.riseup.net; \r
  18 Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18])\r
  19         by mx.perfora.net (node=mxus2) with ESMTP (Nemesis)\r
  20         id 0Lruj8-1O5Es60NN0-013dxj for notmuch@notmuchmail.org;\r
  21         Sat, 02 Jan 2010 13:16:04 -0500\r
  22 Received: from [127.0.0.1] (localhost [127.0.0.1])\r
  23         (Authenticated sender: micah@mx1.riseup.net)\r
  24         with ESMTPSA id 6E3C625E5B9\r
  25 Received: by lillypad (Postfix, from userid 1000)\r
  26         id 52C572CC0BA; Sat,  2 Jan 2010 13:16:13 -0500 (EST)\r
  27 From: micah <micah@riseup.net>\r
  28 To: notmuch@notmuchmail.org\r
  29 Date: Sat, 02 Jan 2010 13:16:12 -0500\r
  30 Message-ID: <87zl4w4bkj.fsf@lillypad.riseup.net>\r
  31 MIME-Version: 1.0\r
  32 Content-Type: multipart/signed; boundary="=-=-=";\r
  33         micalg=pgp-sha512; protocol="application/pgp-signature"\r
  34 X-Virus-Scanned: clamav-milter 0.95.3 at mx1\r
  35 X-Virus-Status: Clean\r
  36 Subject: [notmuch] Queue updates to eliminate write-lock errors\r
  37 X-BeenThere: notmuch@notmuchmail.org\r
  38 X-Mailman-Version: 2.1.12\r
  39 Precedence: list\r
  40 List-Id: "Use and development of the notmuch mail system."\r
  41         <notmuch.notmuchmail.org>\r
  42 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  43         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  44 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  45 List-Post: <mailto:notmuch@notmuchmail.org>\r
  46 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  47 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  48         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  49 X-List-Received-Date: Sat, 02 Jan 2010 18:16:06 -0000\r
  50 \r
  51 --=-=-=\r
  52 \r
  53 \r
  54 I'm sure we are all seeing these occasionally:\r
  55 \r
  56 notmuch-call-notmuch-process: A Xapian exception occurred opening database: Unable to get write lock on .... : already locked\r
  57 \r
  58 It happens when you try to make a change while 'notmuch new' is being\r
  59 run, which is regularly. Typically a 'notmuch new' process doesn't take\r
  60 that long (especially if you are running the newer xapian libraries that\r
  61 fix that bug), but I still find that I am getting that error fairly\r
  62 regularly. It could be because I have a somewhat slow laptop, which has\r
  63 limited memory, CPU and a slow disk, so these updates take longer so I\r
  64 hit that race more frequently than others.\r
  65 \r
  66 In any case, I am sure people have figured out the best way to deal with\r
  67 this already, just the work has to be done, but in case it hasn't been\r
  68 floated yet, what about a queueing layer that accepts interactive\r
  69 changes and attempts to apply them to the backend, backing off and\r
  70 retrying until it can get the xapian lock. That way we can merrily go\r
  71 along and make changes without hitting this locking problem. These\r
  72 changes might have a minor delay before they are applied (until the\r
  73 queue has been flushed), but it would be the same amount of time that we\r
  74 have to wait now, just without the write-lock error.\r
  75 \r
  76 micah\r
  77 \r
  78 --=-=-=\r
  79 Content-Type: application/pgp-signature\r
  80 \r
  81 -----BEGIN PGP SIGNATURE-----\r
  82 Version: GnuPG v1.4.10 (GNU/Linux)\r
  83 \r
  84 iQIcBAEBCgAGBQJLP41sAAoJEIy/mjIoYaeQp2QP/iP6POqncwL/1YG/j7mUcfJz\r
  85 or9Bkpd7cguLo8uZGGryLo5w9oFspZT+VuDBOIzTp8GmRRFXiZ5WopVFhqKG7V8d\r
  86 hL9pa0ULKnP5XG79cRW/3z4pX4EeA2v6CUs6mzlOy+Z/TiFH9dlFzAMuQrdvSEps\r
  87 KE2mkAFd1eTaK1aVWlpi9n3Q7Dre44nt3Qy1NJ5Se/nfB3XWkMtqb3bSoF67fNN7\r
  88 vHI1+W5w5MdPtTcgzWU/LLML3LrbHl52Jl4FtwOztKbuk3dFNEPhPWLPZPZfVGM6\r
  89 0kcOy5MGcwru2TyF+6zjkhHbsQmZxksYmA+8B34szqb9UibKzmq1G7RkolQ6VJxL\r
  90 Ds3IUInQHz6zKlWxaGGRtt56jtCeeL0pSnIhSgiUR/beitA/QeqlfGFO00QO2ci9\r
  91 tMwB2tjlCmktf1qORCjvrWshU9qEGqwh3Y6dia3OM82nDVVmbMH5GLaXFhifapv2\r
  92 2i3vr6h1CMIMDlXUXwMFWbqGxtybQowWmLzC5nTHDyCP8cCIUNSwPk4P+TEpKo0G\r
  93 aOdd/nYlIiz1vN0VQVGSWp/bwtWCQPGK/4eN7jtDJl1C2Xek3m7adjUJYIwcnD/C\r
  94 U556f86GPIdzhzzV174eFl4S2r2sCNlBj4vLR3OXJmxYxHZQp9Tm3BSPyAb4kbEi\r
  95 4tDcZAonV5CF1MtE2/pE\r
  96 =Y46q\r
  97 -----END PGP SIGNATURE-----\r
  98 --=-=-=--\r