similar to: bug: "no top level messages" crash on Zen email loops

On 2018-03-29 04:17:21, Olly Betts wrote: > On Mon, Mar 19, 2018 at 05:03:21PM -0300, David Bremner wrote: >> I can confirm this reproduces both the xapian-check and the notmuch-show >> error. Olly agrees that whatever notmuch is doing wrong, it shouldn't >> lead to a corrupted database > > There was a Xapian bug here, which I fixed on master last week and will >

Antoine Beaupré <anarcat at orangeseeds.org> writes: > Hmm... but if I understand correctly, that's one part of the story: I > could get that error and not have the problem with `notmuch show`. Does > that *also* resolve the issue with email loops? I don't think so, no. d

Matt <mattator at gmail.com> writes: > thanks didn't know about xapian-check ! > the output > === > docdata: > blocksize=8K items=70 firstunused=3 revision=421 levels=0 root=2 > B-tree checked okay > docdata table structure checked OK > > termlist: > blocksize=8K items=186136 firstunused=62058 revision=421 levels=2 root=12260 > B-tree checked okay >

Javier Garcia <javiertury at gmail.com> writes: > I've applied the path to notmuch 0.26.1 without success. > > $ rm -rf ~/.mail/.notmuch > $ LD_LIBRARY_PATH=/hidden-path/notmuch-0.26.1/lib/:$LD_LIBRARY_PATH > ./notmuch new >    Found 20065 total files (that's not much mail). >    Processed 20065 total files in 58s (341 files/sec.). >    Added 19605 new

Mike Hommey <mh at glandium.org> writes: > Hi, > > When running `notmuch compact` today, it stopped with the following > output: > > Compacting database... > compacting table postlist > Reduced by 25% 648656K (2498904K -> 1850248K) > compacting table docdata > Reduced by 15% 24K (152K -> 128K) > compacting table termlist > Reduced by

Running notmuch from git on Debian testing[1] with the mail and database sitting on a ZFS filesystem, adding mail to a new database: > agrajag-testing ~/s/notmuch % ./notmuch new > Found 605510 total files (that's not much mail). > add_file: A Xapian exception occurred36m 37s remaining). > A Xapian exception occurred adding message: Unexpected end of posting list for

Hi notmuch developers, I also had this database corruption, I waited for the fix to land in notmuch 0.26.2, build it, moved the xapian directory away, did a notmuch new and restored the tags from a dump. But the problem remains: ~$ xapian-check ~/Mail/.notmuch/xapian docdata: blocksize=8K items=10841 firstunused=75 revision=82 levels=1 root=2 B-tree checked okay docdata table structure checked

On Mon, Jul 03, 2023 at 02:26:03PM +0200, David Bremner wrote: > "Peter P." <peterparker at fastmail.com> writes: > > > I ran xapian-check on ~/.notmuch/xapian and include its messages > > below at the end of this mail. Everyone please forgive me for > > pasting 1121 there. :) > > H'mm. It doesn't look familiar to me, but I will check with

Unfortunately I can't share my emails without the approval of other parties. The minimum subsets that trigger the error are in the range of 1000-5000 mails, so asking each and everyone of them is out of my reach. I tried to replicate the problem using just spam folders without success. The following is a solid workaround I've stumbled upon. Afew no longer complains and database corruption

On Mon, Mar 19, 2018 at 05:03:21PM -0300, David Bremner wrote: > I can confirm this reproduces both the xapian-check and the notmuch-show > error. Olly agrees that whatever notmuch is doing wrong, it shouldn't > lead to a corrupted database There was a Xapian bug here, which I fixed on master last week and will be fixed in 1.4.6. If changes to a new database which didn't modify

Franz Fellner <alpine.art.de at gmail.com> writes: > I also suffer from bad performance of notmuch new. I used notmuch > some years ago and notmuch new always felt instantanious. Had to stop > using it because internet was too slow to sync my mails :/ Now (with > better internet and a completely new setup using mbsync) indexing one > mail takes at least 10 seconds,

Mueen Nawaz <mueen at nawaz.org> writes: > After a lot of poking around, I figured out the problem, and this may be > of interest to the developers (although not sure if it is a xapian issue > or a notmuch issue). > > Here's why it would freeze: > > I have a post-new hook that runs a Python script. Depending on whether > the new email it is processing matches a

Hi! Suppose you have a huge notmuch/Xapian database, built on a 32-bit system (well, actually on x86_64-pc-linux-gnu, but using a years old 32-bit notmuch binary; notmuch 0.9, Xapian 1.2.21 -- don't laugh), and suppose you're finally going to update that years old notmuch installation (release by release, forward-porting a bunch of patches). Naturally, I'd now do a native 64-bit

"Kirill A. Shutemov" <kirill at shutemov.name> writes: > Hello, > > I found that on particular queries notmuch return different results if run > the query few times. Re-initialing the query or db doesn't help. > > I've attached test case along with corpus of messages. > > Unpack the archive and run `make' there. It will initialize the notmuch

Today we noticed that keywords can't be searched as prefixed terms. Or that's what it looks like anyway. I tested and, or, and not. ╰─% NOTMUCH_DEBUG_QUERY=y notmuch search 'subject:"and"' Query string is: subject:"and" notmuch search: A Xapian exception occurred A Xapian exception occurred parsing query: Syntax: <expression> AND <expression> Query

Ioan-Adrian Ratiu <adi at adirat.com> writes: > I'd like to add a feature to quickly work with mail file sizes > because using custom scripts / external programs which parse > maildir contents is slow, and non-intuitive, especially since > notmuch does incremental parsing and has such a nice emacs UI. I just remembered (and olly confirmed) that there is some work in

David Bremner <david at tethera.net> writes: >> Here's why it would freeze: >> >> I have a post-new hook that runs a Python script. Depending on >> whether the new email it is processing matches a rule I have, >> it will fire off an email to the sender using the SMTP library >> in Python. >> >> I had recently upgraded my MTA

I hadn't noticed any interactive slowdown, but when I got around to running the notmuch performance suite, there seems to be some noticable slowdown with the glass backend (default in Xapian 1.3.5) compared to chert (using xapian 1.2.22) These tests are on an older i7 with 12G of RAM and an SSD. I'm reasonable confident they are CPU bound. One curious thing is the increase in system time

Olly Betts <olly at survex.com> writes: > A better option for this is probably a FieldProcessor - you set one for > a prefix and the it gets passed the value and returns a Query object > for it. E.g. in lua (where you can just pass an anon function for the > FieldProcessor - we ought to support C++11 lambdas for such things): [snip] > To achieve this with synonyms in a

On Tue, Apr 07, 2020 at 05:21:47PM -0300, David Bremner wrote: > Matt <mattator at gmail.com> writes: [...] > > termlist: > > blocksize=8K items=186136 firstunused=62058 revision=421 levels=2 root=12260 > > B-tree checked okay > > termlist table structure checked OK > > > > postlist: > > blocksize=8K items=2598971 firstunused=61412 revision=421