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
