Re: [PATCH] Fix "database is locked" error when committing during rep-cache.db verification

Denis Kovalchuk wrote on Thu, 30 Apr 2020 20:07 +0300:
> I think I've found a problem with the rep-cache.db verification. If a commit
> occurs during the rep-cache.db verification, this can lead to a post-commit
> error "database is locked" and new representations will not be added in the
> rep-cache.db. The problem occurs because during the verification all cache
> entries are retrieved using one large query with holding a sqlite lock, that
> prevents adding new cache entries.
>

So the failure mode is that rep-cache.db entries are not able to be
added while rep-cache.db is being verified. I am not convinced that
this is a problem.

The obvious workaround, in case someone runs into that, is for the
admin to run build-repcache afterwards. (Incidentally, we might want
have the "post-commit FS processing failed" error message namedrop
«svnadmin build-repcache» when the underlying error code indicates an
SQLite error.)

> The problem can occur for other cases where rep-cache.db is changed, such as
> during 'svnadmin build rep-cache'.
>

Yes, build-repcache will error out in this situation. Why is that a problem?

> I propose to retrieve cache entries in batches and process them without holding
> a sqlite lock. I checked that the new approach does not affect the verify
> performance and assume that it should work correctly in the case of concurrent
> working with the rep-cache.db.
>

What effect does the patch have on _correctness_ of verification? What
kinds of corruptions can be detected by the incumbent code but not with
your patch?

> Please see the attached patch. More technical details can be found in the log
> message.

Isn't there an alternative approach that does not affect the correctness
of verification as much as this approach?

Cheers,

Daniel
Received on 2020-04-30 19:56:59 CEST