thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=debian%2F0.35_rc0-1 2022-01-23T01:14:29Z 2022-01-23T01:14:29Z David Bremner david@tethera.net 2022-01-09T14:38:05Z urn:sha1:2786aa4d548d28579c761e9358d44c84dfb29068 Commit [0] left the stemmer object accessible, but did not add de-allocation code to notmuch_database_destroy. This commit corrects that oversight. Leak originally reported by Austin Ray [1]. [0]: 3202e0d1feba1ab955ba1c07098c00208f8f0ada [1]: id:20220105224538.m36lnjn7rf3ieonc@athena 2022-01-15T19:59:39Z David Bremner david@tethera.net 2021-12-25T13:33:05Z urn:sha1:fad2e7540bf9309bfb335650ded753e9ed085eff If we know the configuration is split, but there is no mail root defined, this indicates a (lack of) configuration error. Currently this can only arise in XDG configurations. 2021-10-30T18:04:00Z David Bremner david@tethera.net 2021-10-23T12:27:01Z urn:sha1:c7705fb95e2f5d11fabb7b6a07f7b7558e0928e6 It should not be necesary to have any config information here, hence passing "" to n_d_open_with_config. 2021-09-05T00:07:19Z David Bremner david@tethera.net 2021-08-24T15:17:15Z urn:sha1:9ae4188610dc21101fe9bdeb158854fc7c63463e This will help provide more meaningful error messages without special casing on the client side. 2021-06-27T17:03:00Z David Bremner david@tethera.net 2021-05-18T02:06:01Z urn:sha1:e2a3e5fa51122efb0f5ac836e536881d97deef1a This change addresses two known issues with large sets of changes to the database. The first is that as reported by Steven Allen [1], notmuch commits are not "flushed" when they complete, which means that if there is an open transaction when the database closes (or e.g. the program crashes) then all changes since the last commit will be discarded (nothing is irrecoverably lost for "notmuch new", as the indexing process just restarts next time it is run). This does not really "fix" the issue reported in [1]; that seems rather difficult given how transactions work in Xapian. On the other hand, with the default settings, this should mean one only loses less than a minutes worth of work. The second issue is the occasionally reported "storm" of disk writes when notmuch finishes. I don't yet have a test for this, but I think committing as we go should reduce the amount of work when finalizing the database. [1]: id:20151025210215.GA3754@stebalien.com 2021-06-27T16:58:17Z David Bremner david@tethera.net 2021-05-18T11:03:22Z urn:sha1:65f923219e08193d590bec35e2c3995dc6a19395 Unfortunately, it doesn't make a difference if we call cancel_transaction or not, all uncommited changes are discarded if there is an open (unflushed) transaction. 2021-06-27T16:52:43Z David Bremner david@tethera.net 2021-06-27T16:52:43Z urn:sha1:49893c2c617e0d6874bb9670faa83ddf2324d721 The spacing of the declaration was wrong in ea30110. 2021-06-25T12:20:37Z David Bremner david@tethera.net 2021-06-19T00:59:43Z urn:sha1:ea301102abc55404b8b447cd50998429bfbbf9fd Since most memory allocation is (ultimately) in the talloc context defined by a notmuch_database_t pointer, this gives a more complete view of memory still allocated at program shutdown. We also change the talloc report in notmuch.c to mode "a" to avoid clobbering the newly reported log. 2021-03-27T12:26:14Z David Bremner david@tethera.net 2021-02-23T19:56:47Z urn:sha1:2e39ce6eb5d5e5ae2a2a4ed419190003f47e566e This will allow more precise return values from various open related functions. 2021-03-27T12:26:14Z David Bremner david@tethera.net 2021-02-14T17:42:42Z urn:sha1:a6a580e61613507edc47e0eac0b2b84f6678d01c