Bug#724610: incrementally updated databases eventually become corrupt

[Joey Hess]

Package: libsearch-xapian-perl
Version: 1.2.10.0-1
Severity: normal

ikiwiki's search plugin incrementally updates a xapian index as a wiki
is edited. Certian of my larger wikis tend to corrupt themselves every
month or two, preventing xapian-omega from finding anything.
xapian-check says there is a btree error.

I see this frequently on my main ikiwiki server. But I've heard from
others who have also had this kind of corruption elsewhere so I don't
think it's bad hardware. (I've also migrated my main ikiwiki server to
new hardware at least twice in the years since I started experiencing
this problem.) 

It used to be the case that this could cause
Search::Xapian::WritableDatabase->new to throw an exception, as seen
here:

http://www.branchable.com/bugs/Exception:_Cannot_open_tables_at_consistent_revisions_at___47__usr__47__lib__47__perl5__47__Search__47__Xapian__47__WritableDatabase.pm_line_41./#comment-c159ea3f9be35fcd9ed0eeedb162e816

I have not seen that behavior since upgrading to wheezy. Now when the
database is corrupt, further changes to it don't cause a crash (which is
good); xapian-omega just never finds any matches.

ikiwiki calls methods like add_term and replace_document_by_term and
delete_document_by_term. It may be exercising the incremental update
of xapian databases more frequently than is typical and exposing some
bug. It's also the only thing in Debian that seems to use this perl
library, so it could be that the bug in in this library and not in
xapian itself.

I suppose it's possible that the bug is in ikiwiki. For example, it
could be that two ikiwiki processes end up manipulating the same xapian
database concurrently. I don't know if that is allowed, or likely to
corrupt it. But ikiwiki is supposed to use a lock to prevent two processes
from both making stateful changes at the same time, and I have audited
it and cannot find anywhere that it updates the xapian database without
first taking that lock.

I also wonder if this could be a problem with the flushing of the
database. Ikiwiki relies on the automatic flushing behavior, and assumes
that the database will be closed and flushed automatically when the 
xapian database object is destroyed at program termination. It also
could be the case that ikiwiki sometimes crashes, and this could
interfere with that.

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20130925/33acb3bb/attachment.sig>