Evgeny Kotkov wrote on Tue, Aug 25, 2015 at 02:47:16 +0300:
> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
>
> > My current hypothesis is that the server did not get restarted after
> > replacing the repository. Because we decided not to make the instance ID
> > part of the cache key, we could easily have picked up cached format 6 data
> > for the format 7 repository.
>
> [...]
>
> > That said, are we still happy with the decision to not make the instance
> > ID part of the cache key? The rationale has basically been "fail early"
> > because failure to restart or reconfigure the server after the repo files
> > got modified might lead to any kind of unknown problems (much) further down
> > the road.
>
> As I see it, there are two separate problems:
>
I see it the same way.
> 1) First of all, I am thinking that we should indeed revisit the decision of
> not making instance IDs a part of the cache keys. As far as I recall, this
> part of the change was reverted after we agreed that failing fast is better
> than narrowing the window when the cache issues exist [1] (there are still
> scenarios like backing up and restoring the repository with cp -a).
>
> Now I am almost sure that we should redo this change. The experience of
> receiving errors related to stale cache entries isn't exactly educating,
> but rather than that, it's frustrating, and the procedures describing dump,
> load and hotcopy rarely say something about a server restart. As we have
> the mechanism to make a huge set of cases work without the necessity of
> performing additional actions, I think that we should do it, leaving the
> edge cases as they are. In other words, people who are used to svnadmin
> dump/load/hotcopy shouldn't struggle, because we think that they also could
> be doing something like the aforementioned cp -a.
What are the downsides to having instance IDs as part of the cache key?
I haven't been able to understand that from your post or from Ben's post
you link to (53F4C92B.2010206_at_reser.org), which only mentions a "failure
to clear the cache race that was discussed offlist".
Is this the problem scenario? ---
1. Open an svn_fs_t handle
2. Replace the repository with another repository having the same UUID
but different contents
3. Make a commit from the svn_fs_t opened in (1)
4. The commit creates a corrupted revision due to stale (false positive)
cache hits
?
Thanks,
Daniel
> [1] http://svn.haxx.se/dev/archive-2014-08/0239.shtml
>
>
> Regards,
> Evgeny Kotkov
>
Received on 2015-08-25 08:15:41 CEST