thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=debian%2F0.38_rc2-1 2023-07-22T10:15:59Z 2023-07-22T10:15:59Z David Bremner david@tethera.net 2023-07-20T12:08:01Z urn:sha1:b6f144abe1f5aa3519240cf52f4cb9907fefcd0e It is wasteful to remove a filename term when the whole message document is about to be removed from the database. Profiling with perf shows this takes a significant portion of the time when cleaning up removed files in the database. The logic of n_d_remove_message becomes a bit more convoluted here in order to make the change minimal. It is possible that this function can be further optimized, since the expansion of filename terms into filenames is probably not needed here. 2023-04-02T22:24:43Z David Bremner david@tethera.net 2023-01-06T00:02:06Z urn:sha1:a554690d6af0ac8cb55166a20efd0f449abde389 Instead of skipping indexing all attachments, we check of a (user configured) mime type that is indexable as text. 2022-12-27T15:59:29Z David Bremner david@tethera.net 2022-12-04T02:28:55Z urn:sha1:16d92abf9f3326da1ec0c6f84c2c8876efc77ecb _notmuch_message_delete can return (at least) NOTMUCH_STATUS_XAPIAN_EXCEPTION, which we should not ignore. 2022-06-25T19:06:18Z David Bremner david@tethera.net 2022-05-25T10:51:16Z urn:sha1:3f27cce71f9f154cb0c2134c32d41c31eb62a239 In order for a database to actually be writeable, it must be the case that it is open, not just the correct type of Xapian object. By explicitely checking, we are able to provide better error reporting, in particular for the previously broken test in T566-lib-message. 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.