Hi,

I've been working on an application that keeps a read-only handle on
the notmuch database open for a long time. In some cases when a new
message is added along with some renames of other messages using
'notmuch new' while the application is running I get an Xapian
exception: DatabaseModifiedError:

  A Xapian exception occurred performing query: The revision being
read has been discarded - you
  should call Xapian::Database::reopen() and retry the operation.

Which seems to be printed from: notmuch_query_search_threads ->
notmuch_query_search_messages:294.

I have not been able to make a smaller test case at the moment (this
happens with offlineimap updating an maildir and notmuch new run
afterwards + some tagging).

I can work around this by checking for a NULL pointer returned from
notmuch_query_search_threads () and re-open the database
(notmuch_database_close () -> notmuch_database_open ()). But I have no
way of knowing programatically if this really is the error that has
happened. There should be some way of propagating the error
information or (even better for my case; for notmuch to reopen the
database), one option is the Gmime way of passing an pointer to an
error structure that is filled up by the notmuch interface function.

I made some attempts at exposing the ::reopen() function as suggested
by Xapian (http://xapian.org/docs/apidoc/html/classXapian_1_1Database.html#af140b1f8d948d13cf7be4a11a7c699a4),
but I end up with other errors afterwards. Possibly from leftover
structures created with the original database handle:

after notmuch_database_reopen (see attached patch for your reference):
  A Xapian exception occurred when reading header: Expected block
24615 to be level 1, not 0
  A Xapian exception occurred when reading header: Error reading block
419480589: got end of file
  A Xapian exception occurred when reading date: Error reading block
419480589: got end of file
  A Xapian exception occurred when reading header: Error reading block
419480589: got end of file


as mentioned, doing a manual _close and _open works. Again, the best
would be a consistent way to really know that this (or something else)
is the error that really happened.

Cheers, Gaute