notmuch dump: taking write-lock to protect from concurrent (cronned) notmuch new?

[Mark Walters]

Hi

On Thu, 12 Jun 2014, David Bremner <david at tethera.net> wrote:
> Mark Walters <markwalters1009 at gmail.com> writes:
>
>
>>> mjw1009 suggested to change NOTMUCH_DATABASE_MODE_READ_ONLY on line
>>> 215 of notmuch-dump.c to NOTMUCH_DATABASE_MODE_READ_WRITE
>>>
>>> I'm wondering if this hits enough people to motivate the addition of a
>>> command line switch (or perhaps even a change in default behaviour?)
>>
>> I think this is a clear bug but the fix is a little unclear. The above
>> fix works but it breaks one of the tests: "unicode message-ids" in
>> T150-tagging.sh.
>>
>> I think the problem is that it does 
>> notmuch dump | sed... | notmuch restore
>>
>
> My first reaction was "argh, we should be locking things less, not
> more".  But then I read 
>
>         http://getting-started-with-xapian.readthedocs.org/en/latest/xapian-core-rst/admin_notes.html?highlight=backup#id10
>
> and now I'm not so sure, maybe write lock for dump is the right answer.

On irc Olly said

"I'd suggest locking the db by opening it R/W for the dump at least
until you can use reader locking to keep the read revision valid, but
it'll be a while before that's in a stable release"

and he also said that pipes of the form notmuch dump | ... notmuch
restore will probably fail if they change many tags.

So it is probably the way to go. But it does run the risk of breaking
some peoples (already fragile) scripts.

> It seems hard to do anything sensible with "Database.reopen" in the
> context of a backup.

Yes I agree.

Best wishes

Mark