[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: FSFS rep-cache validation

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Thu, 23 Jan 2014 10:55:12 +0000

Julian Foad <julianfoad_at_btopenworld.com> writes:

> I get the problem. By "store its own 'head' revision" I meant store
> the maximum value of any referenced revision number -- in other words,
> simply a substitute for having an index and querying the maximum value
> in the index. If we update this value correctly then it would serve
> the same purpose as an index (but maybe faster or maybe not). Like
> this:
> Before adding the rep cache entries for a (recently) committed revision rX:
>   if (max_referenced_rev >= X):
>     raise error
>     # caller should escalate the error or clean up the rep-cache
>   max_referenced_rev = X
> Before/during looking up a rep cache entry, when repository head is rY:
>   if (max_referenced_rev >= Y):
>     raise error
>     # caller should escalate the error or clean up the rep-cache
> In a roll-back to revision Z:
>   delete where rep_cache.revision > Z
>   max_referenced_rev = Z
> I suppose the risk involved in users failing to do the roll-back
> correctly (in this case, failing to update max_referenced_rev) would
> still be present which perhaps makes the index approach superior.

That might work but how do we stop old code updating the cache and
failing to update max_referenced_rev? We don't have any version number
in the rep-cache schema so that is going to be ugly. Bump the FS
format? Rename the rep_cache table?

With the index we could have the new code create any missing index when
opening the rep-cache, there would be a one-time delay the first time
new code was used on a big cache. Old code would update the index but
not do the validation check. The validation check done by the new code
would include any rows added by old code.

Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2014-01-23 11:55:47 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.