similar to: modifying the DB while iterating is user error, right?

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 >

I am getting this error when trying to remove a document from my Xapian database via writabledatabase_delete_document: "DatabaseCorruptError: Db block overwritten - are there multiple writers?" There might have been two processes trying to write to it earlier today, but currently only one process can touch it at a time, and I still receive the error. Is there a fast way to fix this

olly wrote: > Log message (7 lines): > backends/database.cc: Database::Internal can't call the > PostingIterator(PostingIterator::Internal*) ctor (at least under > g++ 3.3.5) because it isn't a friend (only class Database is). For the record, Mark just reported this to me under windows so it was a problem there too, but it does work under GCC 4.1. No idea which compiler is

Since a couple of weeks we are experiencing occasional segmentation faults within Xapian 1.5. We can't reproduce the crashes, but we have strong hints that they are due to memory corruption. We have narrowed down our root cause analysis to phrase searches on multi-databases that fail on reading the `hint` field in the`QueryOptimiser`class [1]. We'd appreciate any hints on how to fix this.

Hi Ian, I also found this address in the git history, hoping this works since ian at inspir.es doesn''t. ----- Forwarded message from Eric Wong <normalperson at yhbt.net> ----- From: Eric Wong <normalperson at yhbt.net> To: mongrel-unicorn at rubyforge.org Cc: Hongli Lai <hongli at phusion.nl>, Augusto Becciu <augusto at jadedpixel.com>, I?aki Baz Castillo

On Wed, Jun 19, 2013, at 03:49 PM, Olly Betts wrote: > On Wed, Jun 19, 2013 at 01:29:16PM +1000, Bron Gondwana wrote: > > The advantage of compact - it runs approximately 8 times as fast (we > > are CPU limited in each case - writing to tmpfs first, then rsyncing > > to the destination) and it takes approximately 75% of the space of a > > fresh database with maximum

In case more people are interested, I originally posted the following to ruby-core: http://mid.gmane.org/20101210190448.GA6534 at dcvr.yhbt.net Eric Wong <normalperson at yhbt.net> wrote: > zuerrong <zuerrong at gmail.com> wrote: > > 2010/12/10 Tony Arcieri <tony.arcieri at medioh.com>: > > > And Unicorns are fantastical mythical creatures! > > > >

Hi, I'm not sure if this is some throttling/DoS protection or a bug. I didn't see notice anything like it mentioned looking at the NEWS file from hg, this is on 2.1.7 on Debian stable. I have a client doing IDLE on INBOX.vomiteer. When individual messages arrive with some time interval in between them, I get EXISTS events for each message as expected. However, when I store a bunch of

Hi all. I want to iterate over all the documents in my database. my $pi = $db->postlist_begin(""); while ("$pi" =~ qr/END/) { my $oldid = $pi->get_docid; $pi++; #... } That used to work with Search::Xapian in perl version 1.2, but now with xapian-bindings-1.4.4 it does not seem to. How are you supposed to tell when you have reached the

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

Hi, Trying to learn Search::Xapian and be better at perl at the same time, I'm stuck, at the DB_CREATE_OR_OPEN error. Perl says this: ~/dev/sandbox/Xapian-perl$ ./Index1-Xap.pl 100-objects-v1.csv db "db" is not exported by the Search::Xapian module Can't continue after import errors at ./Index1-Xap.pl line 7. BEGIN failed--compilation aborted at ./Index1-Xap.pl line 7. What I

what is the fastest way to fetch results which are sorted by timestamp ? i want to use xapian as my search engine , use add_boolean_term(something) and add_value(0,sortable_serialise(get_timestamp())) to a doc. search through enquire.set_weighting_scheme(xapian.BoolWeight()) and enquire.set_sort_by_value(0,True) to ensure that the results are sorted by the timestamp. This method is ok , but

I'm trying to compact (or at least merge) multiple databases, while stripping search records which are no longer required. Backstory: I've inherited the Cyrus IMAPd xapian-based search code from Greg Banks when he left Opera. One of the unfinished parts was removing expunged emails from the search database. We moved from having a single search database to supporting multiple

Olly Betts <olly at survex.com> wrote: > On Mon, Aug 24, 2020 at 05:58:02AM +0000, Eric Wong wrote: > > Olly Betts <olly at survex.com> wrote: > > > Can prof report time for a function including things it calls? > > > > callgraph? Attached is a profile the output of "perf report -g" > > with callgraph info. I'm no perf expert,

Olly Betts <olly at survex.com> wrote: > On Fri, Aug 18, 2023 at 10:41:52AM +0000, Eric Wong wrote: > > Olly Betts <olly at survex.com> wrote: > > > While the match is running, get_mset(2000, 1000) needs to track > > > 3000 entries so this won't reduce your heap usage (at least not > > > peak usage). > > > > > > Is the heap

On Thu, Dec 12, 2024 at 09:51:44AM +0100, Jean-Francois Dockes wrote: > Following a discussion a few years ago, Recoll stores the documents text > contents in database metadata entries, with keys derived from document ids. > > More recently an index creation method using several temporary indexes > merged on completion was implemented. This is still a bit experimental. It >

Hi, Following a discussion a few years ago, Recoll stores the documents text contents in database metadata entries, with keys derived from document ids. More recently an index creation method using several temporary indexes merged on completion was implemented. This is still a bit experimental. It brings a significant speed increase in some cases. I just realised that the merge lost many

Hi there, My web app uses Xapian via the PHP bindings. I'm getting this error thrown occasionally when atempting to instantiate a XapianDatabase object for searching. DatabaseCorruptError: Expected block 107 to be level 1, not 0 Here's the line that invokes it: $database = new XapianDatabase(PROJROOT.'/data/xapian/posts'); And my version is xapian-core 1.2.3 with matchspy.

Xapian (0.7.5) is spitting out this error on a regular basis: org.xapian.errors.DatabaseError: Error reading block 136618: got end of=20= file =A0=A0=A0=A0=A0=A0=A0 at=20 org.xapian.XapianJNI.writabledatabase_repalce_document(Native Method) =A0=A0=A0=A0=A0=A0=A0 at=20 org.xapian.WritableDatabase.replaceDocument(WritableDatabase.java:67) I don't have a gdb backtrace, only the Java

Ocassionally when I'm searching using Omega I get: "DatabaseCorruptError: Cannot open tables at consistent revisions" If I click reload it's all ok, is this the database being updated?, is there a way to avoid the message? Frank