yes, i can. here's how to reproduce it on master:

fire a `notmuch tag +TEST1 '*'`, which should block the db for a while.
Then use the attached script to write to the index (this could make a nice
second testcase for the bindings in case the test body is large enough).

On master, the script fails like this:

A Xapian exception occurred opening database: Unable to get write lock on
/home/pazz/mail/.notmuch/xapian: already locked
Segmentation fault

When you reset using `git reset e92b438f46a3a` (to 4winters first patch), the script
fails like this, which is the intended behaviour:

A Xapian exception occurred opening database: Unable to get write lock on /home/pazz/mail/.notmuch/xapian: already locked
Traceback (most recent call last):
  File "./p.py", line 3, in <module>
    db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
  File "/usr/local/lib/python2.7/dist-packages/notmuch/database.py", line 121, in __init__
    self.open(path, mode)
  File "/usr/local/lib/python2.7/dist-packages/notmuch/database.py", line 173, in open
    raise NotmuchError(message="Could not open the specified database")
notmuch.globals.NotmuchError: Could not open the specified database


best,
/p


Quoting Sebastian Spaeth (2011-12-06 11:12:42)
>On Tue, 06 Dec 2011 10:46:31 +0000, Patrick Totzke <patricktotzke@googlemail.com> wrote:
>> This commit breaks raising XapianErrors for me.
>> 
>> If I lock the index with some `notmuch tag +test '*'`
>> and try to write to it in alot, i get a segfault and
>> the following on stderr:
>> 
>> Xapian exception occurred opening database: Unable to get write lock on
>> /home/pazz/mail/.notmuch/xapian: already locked
>
>Can you confirm that this only occurs with this patch and not without?
>To be honest, I don't see how the patch would change things in a way
>that make it throw XapianErrors that would not also occur before this
>patch.
>
>Sebastian