similar to: Strange index consistency issue

Olly Betts <olly <at> survex.com> writes: > > You could try: > > delve -t '' ./xapiandb > > That will list the document lengths, so you can see if document 6 is in > that list or not. I am the recoll user mentioned in the first post above. I still have a copy of the (potentially) corrupted index and I did the requested testing. I ran delve -t

Olly Betts writes: > On Wed, May 17, 2017 at 09:08:32PM +0200, Jean-Francois Dockes wrote: > > I have a user reporting the following error during recoll indexing: > > > > flush() failed: Db block overwritten - are there multiple writers? > > > > "flush() failed" is from recoll, the rest is, I think the text of the Xapian > > exception.

A Recoll user gets the following message while indexing: "Attempted to delete or modify an entry in a non-existent posting list for #bannerholder" The exception happens during a commit call. Xapian version 1.4.11, Debian Buster A little more detail here: https://opensourceprojects.eu/p/recoll1/tickets/108/ I asked if this was reproducible, and to run the indexing in single-thread

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

Olly Betts writes: > On Sun, Jan 10, 2016 at 02:53:14AM +0000, Bob Cargill wrote: > > I am the recoll user mentioned in the first post above. I still have a copy > > of the (potentially) corrupted index and I did the requested testing. > > > > I ran delve -t '' ./xapiandb on the index and it returned a very long list > > of document IDs, separated

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

Olly Betts <olly <at> survex.com> writes: > > On Thu, Jan 14, 2016 at 11:04:29AM +0100, Jean-Francois Dockes wrote: > > Olly Betts writes: > > > On Sun, Jan 10, 2016 at 02:53:14AM +0000, Bob Cargill wrote: > > > > I will look into the bug you listed to see if it might be related. If there > > > > is anything else that I can do, please

Hi, I have a user reporting the following error during recoll indexing: flush() failed: Db block overwritten - are there multiple writers? "flush() failed" is from recoll, the rest is, I think the text of the Xapian exception. This is with Xapian 1.4.3 on Linux (I asked for more details, should be coming). I don't think that I've ever seen this error, and I also

Dear senior ML members and developers of Xapian Omega, Mr. Olly has helped me cross the bump of the initial learning curve. (ref: https://lists.xapian.org/pipermail/xapian-discuss/2024-April/010034.html) How can I use Xapian Omega directly (i.e., without using `recoll` and `xapiandb`) to index a directory of text files with all strings greater than 3 characters, to create an index text file

On Mon, May 22, 2017 at 07:45:59AM +0200, Jean-Francois Dockes wrote: > Olly Betts writes: > > Assuming nobody deleted the log file, this could be a Xapian bug. This I meant "lock file" not "log file" here. > > isn't something we're drowning in reports of, so presumably it doesn't > > trigger easily, so finding a way to reproduce would be

Greets, I've encountered the following while performing test merges (and writing code to handle errors, etc so things can be automated) and wondering about the best way to proceed: xapian-compact -b64k -m src1 src2.... tmp_dst -- works as expected, exit code 0. xapian-check tmp_dst -- produces the following error for the postlist: postlist: baseB blocksize=64K items=28175410

On Sun, Jan 10, 2016 at 02:53:14AM +0000, Bob Cargill wrote: > I am the recoll user mentioned in the first post above. I still have a copy > of the (potentially) corrupted index and I did the requested testing. > > I ran delve -t '' ./xapiandb on the index and it returned a very long list > of document IDs, separated by spaces. I than ran delve -t '' ./xapiandb |

On Thu, 18 Apr 2024 at 06:24, Olly Betts <olly at survex.com> wrote: [ ... ] > Yes - it's in the xapian-omega package you already have installed: > > /usr/lib/cgi-bin/omega/omega Thank you, Mr. Betts. for your replying to my questions. Please consider me a novice and elaborate further, Mr. Betts. > You may need to configure apache to tell it to use this for a URL on

On Mon, Aug 26, 2019 at 09:42:09AM +0200, Jean-Francois Dockes wrote: > A Recoll user gets the following message while indexing: > > "Attempted to delete or modify an entry in a non-existent posting list for #bannerholder" > > The exception happens during a commit call. Xapian version 1.4.11, Debian Buster > > A little more detail here:

Hi, I have had a problem report from a Recoll user about the amount of writes during index creation. https://opensourceprojects.eu/p/recoll1/tickets/67/ The issue is that the index is on SSD and that the amount of writes is significant compared to the SSD life expectancy (index size > 250 GB). >From the numbers he supplied, it seems to me that the total amount of block writes is roughly

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

On 14/09/2018 at 09:30, Jean-Francois Dockes wrote: > Hi, > > You may be interested by how Recoll does it: > > https://www.lesbonscomptes.com/recoll/idxthreads/threadingRecoll.html > > A few things in the document are slightly obsolete (esp. the last > paragraph: recollindex now does use vfork()), but it's overall quite close > to how the current indexer works.

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? > >

On Thu, Apr 18, 2024 at 03:46:53PM +0530, Susmita/Rajib wrote: > On Thu, 18 Apr 2024 at 06:24, Olly Betts <olly at survex.com> wrote: > > You may need to configure apache to tell it to use this for a URL on > > your site. > > How Mr. Betts? Suppose I have a ready open document text file, a > LibreOffice text file. say BettsBio.odt, for which I want to create an >

Olly Betts writes: > On Mon, Jan 21, 2019 at 03:25:01PM +0100, Jean-Francois Dockes wrote: > > I have had a problem report from a Recoll user about the amount of writes > > during index creation. > > > > https://opensourceprojects.eu/p/recoll1/tickets/67/ > > > > The issue is that the index is on SSD and that the amount of writes is > >