Re: v4 of DB_RETRY_LOCK patches

On Sun, Jun 26 2016, David Bremner wrote: > This obsoletes > >id:1465043356-23420-2-git-send-email-da...@tethera.net > > I investigated adding a timeout (including talking a bit to Xapian > upstream about it), and thought about some runtime configuration > options, but for

Re: v4 of DB_RETRY_LOCK patches

Thanks for getting this into shape, LGTM. FWIW, I have been running with DB_RETRY_LOCK for the past couple of months on a fairly large mail spool (500K emails), a high incoming volume and many tagging rules. So far it's been working great. No deadlocks, any delays waiting for locks are barely

[PATCH 1/3] Use the Xapian::DB_RETRY_LOCK flag when available

From: Istvan Marko Xapian 1.3 has introduced the DB_RETRY_LOCK flag (Xapian bug 275). Detect it in configure and optionally use it. With this flag commands that need the write lock will wait for their turn instead of aborting when it's not immediately available. Amended by

[PATCH 2/3] test: initial tests for locking retry

Currently there's not much to test, so we simulate contention, and check that the modifications to the database are serialized. --- test/T620-lock.sh | 75 +++ 1 file changed, 75 insertions(+) create mode 100755 test/T620-lock.sh diff --git

[PATCH 3/3] lib: add built_with handling for XAPIAN_DB_RETRY_LOCK

This support will be present only if the appropriate version of xapian is available _and_ the user did not disable the feature when building. So there really needs to be some way for the user to check. --- lib/built-with.c| 2 ++ notmuch-config.c| 3 +++ test/T030-config.sh | 1 +

v4 of DB_RETRY_LOCK patches

This obsoletes id:1465043356-23420-2-git-send-email-da...@tethera.net I investigated adding a timeout (including talking a bit to Xapian upstream about it), and thought about some runtime configuration options, but for now I settled on a configure. Depending what experiences people report, we