similar to: xapian.DocNotFoundError: regression?

Hi, I've a program which: 1. Sets XAPIAN_FLUSH_THRESHOLD=1000 2. Opens a (new) database for write 3. Indexes a few thousand documents 4. Periodically also does queries on the database With 1.1.4, with certain document sets (basically a particular mail folder of mine), Enquire.get_mset() sometimes (but not always) triggers a "RangeError: Value in posting list too

Hello, I'm using Xapian 1.0.2 (flint) and matching Search::Xapian. I'm getting: terminate called after throwing an instance of 'Xapian::DocNotFoundError', which dumps core. at first it was after adding my 2nd document (to an empty db, although I don't know if that has any bearing) to the database with a replace_document() call. I shifted the first document off the

I've traced a memory leak to a statement which assigns the values from an MSetItem to a dictionary which is then appended to a list in python. We're running python 2.7.3, xapian-core 1.2.15 and xapian-bindings 1.2.15. I've provided an example which reproduces the behavior below. The example prints the PID and has a few statements waiting for input to make observing the behavior easier.

On Fri, Aug 21, 2009 at 02:44:44PM +0200, emmanuel at engelhart.org wrote: >> I want to update my request. >> Is my question bad formulated? too trivial? ... or maybe pretty >> complicated/unclear? > >I think nobody answered as it was hard to follow your example because >the Burmese characters seem to have been mangled (at least the message I >received wasn't

Dear Members of Xapian Project, Sorry for troubling you this time. It can be witnessed that xapian will store Document values with serialization approach when given value types meet float/double. Such an approach is deployed on sort_key related fields as well, where the xapian requires KeyMaker::operator() must return an serialized float/dobule variable. Then heap sort comes and ranks

Olly, the process size does stay constant with the results from one query set, but running other queries will cause it to grow (once). Is it possible that this is a bug with the SWIG python bindings? On Fri, Jul 5, 2013 at 6:18 AM, Olly Betts <olly at survex.com> wrote: > On Wed, Jul 03, 2013 at 03:59:21PM -0400, Jeff Rand wrote: > > Run the following code and monitor the

Currently, the SWIG generated bindings catch exceptions raised by Xapian and rethrow them using the standard SWIG error types: for example, if any Xapian::DatabaseError exception is raised, SWIG will use its standard SWIG_IOError error type to report the error. In Python, this leads to code like the following: try: db.get_document(1) except RuntimeError, e: if

Currently, the SWIG generated bindings catch exceptions raised by Xapian and rethrow them using the standard SWIG error types: for example, if any Xapian::DatabaseError exception is raised, SWIG will use its standard SWIG_IOError error type to report the error. In Python, this leads to code like the following: try: db.get_document(1) except RuntimeError, e: if

Hello, i switched from one big index to a stub file with many indexes and running into a problem. i have a tool to fetch a random document via: get_doccount random id up to get_doccount get_document with that id after changing to stub file this failes. Is there a nice way to get a random document from a stub file? ?MfG? Felix Ostmann

Hi, A Recoll user is reporting an index corruption problem. In general, index corruption happens from time to time with Recoll, because of crashes, reboots, misc Recoll bugs, etc. The strange thing here is that xapian-check does not seem to detect anything. In a nutshell, some document numbers seem to point to a data blackhole: the docids are returned when searching for the file/doc unique

> > > I'd prefer to avoid adding things to the public API that don't get > used by end users. However because LTR is outside the Xapian build > tree, we can't easily give it privileged access to Xapian internals. > Sorry for a delayed response. The way I was thinking of performing reranking with updated weights was to add a class MSetRanker (basically containing a

I seem to be seeing cases where I call db.delete_document(somedocid) with no error, then flush() and delete the database object, but the document is still there after process exit. The write lock is normally deleted, so it appears that the database close finished normally. If I then then call delete_document(somedocid) from another command/process, this time it goes away. I've been seeing

On Fri, Jan 08, 2016 at 08:11:48AM +0100, Jean-Francois Dockes wrote: > A Recoll user is reporting an index corruption problem. In general, index > corruption happens from time to time with Recoll, because of crashes, > reboots, misc Recoll bugs, etc. > > The strange thing here is that xapian-check does not seem to detect anything. Checking the database checks the B-tree

Sorry if this is a repost .. I have edited my query a little bit and my previous post was too long and so was waiting approval(I cancelled it) Ok. Another question.. I have installed the Search ::Xapian on my local machine. Now I'm trying to install it on a machine where i dont have root access. So while running configure of the Xapian library I gave the -prefix option and everything installed

Hi everyone, Let me briefly describe my setup. I work at a small university and we are setting up 3 labs. 2 are filled with Ultra Sparc 5's, and the 3rd will be filled with PCs running NT4 workstation. We have an Enterprise Server 3500 running NIS+ to authenticate the Unix labs (or rather we will, once I get it working), and I'd like to set up Samba to authenticate the NT labs using