> 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.
I think that this case leads to multiple problems:
1) Commits happening at the same time as verify will hang for the duration of
sqlite busy timeout.
2) These commits will complete with a post-commit error.
3) No entries will be added to rep-cache.db. Unless fixed, following commits
may work without deduplication.
Repository verification can be a regular procedure and can take a long time for
large repositories. And in that case the mentioned problems can also happen
regularly.
> 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.)
I assume that the patch fixes the problem in such a way that it does not
require any additional workarounds and does not worsen any other
characteristics. At the same time, I would like to note that the workaround
does not fix all problems. It fixes only 3) and only if it is called at the
right time.
> Yes, build-repcache will error out in this situation. Why is that a problem?
I think this is a problem for similar reasons. It may be unexpected that the
read-only verify operation can lead to an error when another maintenance
operation such as 'svnadmin build-repcache' is called. To completely avoid
failures, it may be necessary to separate operations by time, and this is not
always possible.
> 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?
>
> Isn't there an alternative approach that does not affect the correctness
> of verification as much as this approach?
The patch does not change the verification process, only the process of
fetching entries. In the previous approach entries were fetched during one
large query and now they are fetched in small batches.
In this way:
1) If rep-cache.db is not changed during its verification, the new approach
should be equivalent to the previous one.
2) If new entries are added to the rep-cache.db during its verification, the
new approach has a guarantee that all entries that existed at the time of the
call of 'svnadmin verify' will be verified.
So I think that it should not affect the correctness of verification.
Regards,
Denis Kovalchuk
Received on 2020-05-01 23:28:44 CEST