Re: A systematic way of handling Xapian lock errors?
[notmuch-archives.git] / 18 / eb03e9391e339cc041a0273c29898834d8592e
1 Return-Path: <dkg@fifthhorseman.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 arlo.cworth.org (Postfix) with ESMTP id 89C436DE0159\r
6  for <notmuch@notmuchmail.org>; Fri,  3 Jun 2016 07:40:16 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.019\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5\r
12  tests=[AWL=-0.019] autolearn=disabled\r
13 Received: from arlo.cworth.org ([127.0.0.1])\r
14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
15  with ESMTP id aLCCyf6hSxsW for <notmuch@notmuchmail.org>;\r
16  Fri,  3 Jun 2016 07:40:08 -0700 (PDT)\r
17 Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118])\r
18  by arlo.cworth.org (Postfix) with ESMTP id 626FD6DE0297\r
19  for <notmuch@notmuchmail.org>; Fri,  3 Jun 2016 07:38:36 -0700 (PDT)\r
20 Received: from fifthhorseman.net (unknown [38.109.115.130])\r
21  by che.mayfirst.org (Postfix) with ESMTPSA id 0991DF98B;\r
22  Fri,  3 Jun 2016 10:38:32 -0400 (EDT)\r
23 Received: by fifthhorseman.net (Postfix, from userid 1000)\r
24  id 6990320217; Fri,  3 Jun 2016 10:38:32 -0400 (EDT)\r
25 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
26 To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org\r
27 Subject: Re: [RFC2 Patch 5/5] lib: iterator API for message properties\r
28 In-Reply-To: <8737oufn6f.fsf@zancas.localnet>\r
29 References: <1463927339-5441-1-git-send-email-david@tethera.net>\r
30  <1464608999-14774-1-git-send-email-david@tethera.net>\r
31  <1464608999-14774-6-git-send-email-david@tethera.net>\r
32  <8760tthfuy.fsf@zancas.localnet> <87pos1u14p.fsf@alice.fifthhorseman.net>\r
33  <87eg8ht2sb.fsf@alice.fifthhorseman.net> <87lh2ofpxk.fsf@zancas.localnet>\r
34  <87inxrqyv1.fsf@alice.fifthhorseman.net> <8737oufn6f.fsf@zancas.localnet>\r
35 User-Agent: Notmuch/0.22+16~g87b7bd4 (http://notmuchmail.org) Emacs/24.5.1\r
36  (x86_64-pc-linux-gnu)\r
37 Date: Fri, 03 Jun 2016 10:38:28 -0400\r
38 Message-ID: <87y46mpcbf.fsf@alice.fifthhorseman.net>\r
39 MIME-Version: 1.0\r
40 Content-Type: multipart/signed; boundary="=-=-=";\r
41  micalg=pgp-sha512; protocol="application/pgp-signature"\r
42 X-BeenThere: notmuch@notmuchmail.org\r
43 X-Mailman-Version: 2.1.20\r
44 Precedence: list\r
45 List-Id: "Use and development of the notmuch mail system."\r
46  <notmuch.notmuchmail.org>\r
47 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
48  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
49 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
50 List-Post: <mailto:notmuch@notmuchmail.org>\r
51 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
52 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
53  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
54 X-List-Received-Date: Fri, 03 Jun 2016 14:40:16 -0000\r
55 \r
56 --=-=-=\r
57 Content-Type: text/plain\r
58 \r
59 On Fri 2016-06-03 08:54:00 -0400, David Bremner wrote:\r
60 > Sure, where do you think that kind of documentation is appropriate?\r
61 > There is the giant comment about the database schema in\r
62 > lib/database.cc. Actually I just noticed I already failed to update that\r
63 > for libconfig stuff.\r
64 \r
65 That comment seems OK, but it won't be exposed to the people who are in\r
66 that middle range (python or ruby programmers but not C programmers).\r
67 Do we have a place for this kind of mid-level documenation?\r
68 \r
69 > [ dkg wrote: ]\r
70 >>  * for messages which have multiple files, which file is actually indexed\r
71 >\r
72 > yes. Although rather than storing that, I think the right answer is more\r
73 > like "all of them".\r
74 \r
75 I don't think we do this, do we?  Is this a bug?  is it tracked somewhere?\r
76 \r
77 >> It's worth noticing that the stuff in "elsewhere" is the stuff that\r
78 >> won't propagate across a dump/restore unless it's explicitly in the dump\r
79 >> somehow.   We currently fail to restore thread-id and which file is\r
80 >> actually indexed across a dump/restore :/\r
81 >\r
82 > The thread-id is in some sense derived from the message itself. Not in a\r
83 > reproducable way, but still, the dump file is the minimal set of extra\r
84 > data needed to reconstruct an equivalent database (pax threading bugs).\r
85 \r
86 This is exactly my point -- i don't care about reproducibility of the\r
87 exact numbering, but , the thread-id is *not* reproducible from the\r
88 message sets.  This is not only because of the ghost message leakage bug\r
89 documented in T590-thread-breakage.sh, but also because threads can be\r
90 joined by a message that is later removed (e.g., the "notmuch-join"\r
91 script in id:87egabu5ta.fsf@alice.fifthhorseman.net ).\r
92 \r
93 >> I think you've convinced me that it's good to go ahead with the\r
94 >> properties, assuming it's scoped as defined above.  I still think that\r
95 >> we need a better story for upgrades to the dump format in general, but\r
96 >> maybe this isn't the place to make that particular case.\r
97 >\r
98 > I'm not sure what you have in mind, something more ambitious than the\r
99 > header added post 0.22?\r
100 \r
101 Can you point me to the definition for that header?  i still don't\r
102 understand what the batch-tag:2 part means.  (sorry i haven't been\r
103 keeping up with the master branch lately!)\r
104 \r
105            --dkg\r
106 \r
107 --=-=-=\r
108 Content-Type: application/pgp-signature; name="signature.asc"\r
109 \r
110 -----BEGIN PGP SIGNATURE-----\r
111 Version: GnuPG v2\r
112 \r
113 iQJ8BAEBCgBmBQJXUZZkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
114 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy\r
115 NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcK9vEP/jDBCHYh5Y5s+3bNE//dkGTU\r
116 3/739tfdWDO58ALmW101VZj6WDEph1nxe/4Iw0P13CCmLbUmRyU28yYJF5XxyiQH\r
117 eYMk2I3QJxOl1++nhZIoT/ztSCsAJKNK1V4YtJAIiiAbF/ok7qqmwe5BFRiiowEh\r
118 xqAb1eVkLhHJce71NpjdDQ0ItLqH6w3rbV+VuxnvZbnla+w6hbX7TOJsPv3tdXA4\r
119 lMGuKcHMNUmXeP1FA4MdoqQmluybSL1qxC8W8XraKcduDuA3H22IzPEXdPu6Mr07\r
120 bCVS8Jiu3o8ITPtjGDDUfaWZfT/+BV02vChMrrXKHJwOb1NHAnlwRhpo3sFqHcNL\r
121 O2WZyBU0Ti8yb3rpgBkT6k1Hl+im9jfV3SN0HrqE6LrDiL2eCl3uJKSYSAxPv+KT\r
122 3UnQOLdgACGpfjZC+fqRLtXccYjd8QsLfUN+YJeP5/ZHlfruKYkp4hxeOwsCipPA\r
123 cARmXXH0SdFDT+WdYqlIvgM6gNAaZgb9pMyzPnSBTQmf0GT9IK8rnmkCbsYcnMYk\r
124 MfpUwq/YjrVpq4L7HOtrYrUXs8AngzVnE1nMkqXunBR1MOIQVkV9Ct+k9RUwwnkl\r
125 gkKhRpp0n8OdqqSDn7z3aTCniT0o9/wKLt8B+8UbVdqWag5TuH2su4knXji4B6Dw\r
126 cbBqu8U7jUV4RbSRDlqA\r
127 =QSUx\r
128 -----END PGP SIGNATURE-----\r
129 --=-=-=--\r