Displaying 20 results from an estimated 300 matches similar to: "Writing an FTS plugin"
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
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
2016 Feb 21
5
Database left unlocked by Tcl bindings
I discovered, while trying to set up Tcl bindings for Notmuch
(https://notmuchmail.org/), which uses Xapian, that flintlock was not
being locked (I had lost updates).
I then found that opening a Xapian database for writing directly via
the Xapian Tcl bindings also silently fails to lock flintlock.
I have taken a copy of flint_lock.cc to play with, and I find that it
locks the file when called
2019 Jan 13
0
Solr -> Xapian ?
I found the solution o this using
SEQ_RANGE_ARRAY_ADD(&RESULT->DEFINITE_UIDS, UID);
Now, I can see in the logs that several times, the dovecot calls the
fts_backend_xapian_update_set_mailbox with box == NULL. WHy so ?
THank you
On 2019-01-12 21:40, Joan Moreau via dovecot wrote:
> I somehow fixed the folder issue. (seems some unix rights after too many tests)
>
> Getting
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
2019 Jan 12
2
Solr -> Xapian ?
I somehow fixed the folder issue. (seems some unix rights after too many
tests)
Getting back on the "fts_results" structure:
I am trying:
I_ARRAY_INIT(&(RESULT->DEFINITE_UIDS),R->SIZE);
I_ARRAY_INIT(&(RESULT->MAYBE_UIDS),0);
uint32_t uid;
for(i=0;i<r->size;i++)
{
try
{
2017 Mar 09
3
Inconsistent query results
"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
2016 Feb 22
3
Database left unlocked by Tcl bindings
On Sun, 21 Feb 2016 22:33:22 +0000, Olly Betts <olly at survex.com> wrote:
> On Sun, Feb 21, 2016 at 02:15:25PM +0100, Eric J wrote:
> > I discovered, while trying to set up Tcl bindings for Notmuch
> > (https://notmuchmail.org/), which uses Xapian, that flintlock was not
> > being locked (I had lost updates).
>
> It seems to work for me, testing with this:
>
2012 Jan 26
3
Puppet Dashboard 1.2.5 Available [security update - moderate]
Welcome to the first Puppet Dashboard maintenance release of the new year.
This release includes a security update to address CVE-2012-0891, a
XSS vulnerability discovered by David Dasz <david@dasz.at>. We have
classified the risk from this exposure as moderate. All Puppet Dashboard
users are encouraged to upgrade when possible.
Puppet Enterprise users
should visit
2007 Sep 05
2
auth_default_realm for different listeners
We provide POP3 service for several realms, each of which has a substantial
number of users logging in with no realm (bare username). We would like to
use Dovecot, but I haven't been able to findout how to vary
auth_default_realm for each listener.
My most recent attempt was to set up one auth {} block for each realm with a
different auth_default_realm and socket master path. I then set up
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
>
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
2018 Sep 10
3
Notmuch DB Problems
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
2020 Apr 20
4
performance problems with notmuch new
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,
2019 Jul 09
2
Transitioning notmuch/Xapian from 32-bit to 64-bit system
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
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
2018 Sep 29
2
xapian parser bug?
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
2023 Jul 04
1
Internal error: Message without type term
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
2016 Apr 08
2
slowdown in notmuch perf suite with xapian 1.3.5
Olly Betts <olly at survex.com> writes:
>
> So the T00-new.sh numbers make sense - there's more work to do, and
> we need to read existing positional data more to insert the new stuff,
> so the increased reads and writes make sense.
>
> But guessing at what the other two tests do, I wouldn't expect them to
> be affected by this.
The non-optimized-away cases of
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