[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.