Evgeny Kotkov wrote on Tue, Aug 25, 2015 at 02:47:16 +0300: > Stefan Fuhrmann <stefan.fuhrm...@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.2010...@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 >
