similar to: Error while compacting: Bad position key

Displaying 20 results from an estimated 700 matches similar to: "Error while compacting: Bad position key"

2018 Apr 29
1
Database corruption after clean rebuild
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
2020 Apr 07
2
crash after running notmuch new
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 >
2018 Apr 07
3
Database corruption after clean rebuild
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
2017 Dec 29
2
notmuch: Xapian exception during database creation
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
2017 Dec 29
0
notmuch: Xapian exception during database creation
On Fri, Dec 29, 2017 at 03:00:47PM +0000, David Edmondson wrote: > 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).
2018 Apr 07
1
Database corruption after clean rebuild
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
2018 Apr 29
0
Database corruption after clean rebuild
Gregor Zattler <telegraph at gmx.net> writes: > 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
2020 Apr 07
0
crash after running notmuch new
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
2017 Feb 27
2
errors on rebuild
Hello, I am trying to rebuild an index of 2+ million documents and have not been successful. I am running Python 2.7 Django 1.7 Haystack 2.1.1 Xapian 1.2.21 The index rebuild command I’m using is: django-admin.py rebuild_index --noinput --batch-size=100000 The rebuild completes but an immediate xapian-check returns this error: xapian-check ./archive_index record: baseB blocksize=8K
2017 Feb 28
0
errors on rebuild
On Mon, Feb 27, 2017 at 10:29:46AM -0800, Ryan Cross wrote: > I am trying to rebuild an index of 2+ million documents and have not been successful. I am running > > Python 2.7 > Django 1.7 > Haystack 2.1.1 > Xapian 1.2.21 > > The index rebuild command I’m using is: django-admin.py rebuild_index --noinput --batch-size=100000 > The rebuild completes but an immediate
2016 Apr 11
2
Xapian 1.3.5 snapshot performance and index size
Olly Betts writes: > On Sun, Apr 10, 2016 at 04:47:01PM +0200, Jean-Francois Dockes wrote: > > Some might notice the 50% index size increase. Excessive index size is > > already one relatively rare, but recurring complaint. Except if I did > > something wrong: I'm actually quite surprised by it. > > Did you try compacting the resulting databases? > >
2017 Mar 25
0
errors on rebuild
Hi Olly, After upgrades my stack is now: Python 2.7 Django 1.8 Haystack 2.6.0 Xapian 1.4.3. (latest xapian haystack backend with some modifications) Using the same rebuild command as below but with —batch-size=50000 The issue has now become one of performance. I am indexing 2.2 million documents. Using delve I can see that performance starts off at about 100,000 records an hour. This is
2017 Mar 02
2
errors on rebuild
Hi Olly, Thanks for the detailed response. I hadn’t realized there was a new xapian haystack backend. I’m going to try that but I have some upgrades to do first. Django 1.8, etc. Thanks, Ryan > On Feb 28, 2017, at 3:40 PM, Olly Betts <olly at survex.com> wrote: > > On Mon, Feb 27, 2017 at 10:29:46AM -0800, Ryan Cross wrote: >> I am trying to rebuild an index of 2+
2010 Jan 14
1
Latest revision and backwards compatibility
Greetings, I've been wondering about the index format and backwards compatibility. We're using the dev version (for chert) and each svn up means that any indexes created prior to this revision cannot be read. Is this purely a cautious move to prevent errors, and, barring any obvious index format changes, can I safely force the current revision to read existing indexes? eg, by
2014 May 10
2
some trouble when devising skiplist
Hi, I was confronted with some trouble, I describe the trouble in my journal http://trac.xapian.org/wiki/GSoC2014/Posting%20list%20encoding%20improvements/Journal#May10 And corresponding code is in my git. Would you like to give me some help? ------------------ Shangtong Zhang,Second Year Undergraduate, School of Computer Science, Fudan University, China. -------------- next part
2020 Apr 24
1
performance problems with notmuch new
On Thu Apr 23 00:21:30 2020, Olly Betts <olly at survex.com> wrote: > First question: what version of Xapian are you using? On my laptop it's 1.4.15 (arch linux) and the desktop runs 1.4.14 (Gentoo linux) > And second thing to check, are you committing each message separately? No, I sync with mbsync which dosnloads a bunch of mails, then I run notmuch new which indexes all in
2016 Apr 12
2
Xapian 1.3.5 snapshot performance and index size
Olly Betts writes: > On Mon, Apr 11, 2016 at 09:54:36AM +0200, Jean-Francois Dockes wrote: > > The question which remains for me is if I should run xapian-compact > > after an initial indexing operation. I guess that this depends on the > > amount of expected updates and that there is no easy answer ? > > I think it's not obvious whether it's a good plan
2012 Jul 17
1
Can not use custom weight scheme with python binding
Hi, I'm trying to use custom weight with python binding. My test code is like this. class TinkerWeight(xapian.Weight): def __init__(self): pass def name(self): return "Tinker" def serialize(self): return "" def get_sumpart(*args): return 1 def get_maxpart(*args): return 1 def get_sumextra(*args):
2018 Mar 19
2
bug: "no top level messages" crash on Zen email loops
Antoine Beaupré <anarcat at orangeseeds.org> writes: > On 2018-03-19 13:36:49, David Bremner wrote: >> >> I can't duplicate that part. > > That's very strange. I can reproduce this on my workstation here, but > taking the tarball I sent in the original message, I can't reproduce > anymore. So something changed! I suspect it's the
2018 Mar 29
2
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 >