[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: Mon, 27 Jan 2014 11:47:05 +0000

Philip Martin <philip.martin_at_wandisco.com> writes:

> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
>> But we do write the database strictly in revision order.
>> So, if we could simply read the latest record once upon
>> opening the DB. If that refers to a future revision, read
>> "current" and compare. If the DB it still "in the future",
>> abort txn, i.e. prevent any future commit until rep-cache.db
>> gets deleted by the admin.
> That might work. The rep-cache for a new revision is not written
> strictly in revision order but is written after updating HEAD. So such
> a check would not be as strong as "highest revision" but would be a
> useful extra check if we can implement it efficiently it without a table
> scan. Is sqlite3_last_insert_rowid() the function we want?

Bert pointed out that is the wrong function and there isn't really a
suitable function. So to do this check we need something like
Julian'ssuggestion: a one row table containing the most recent revision
added to the rep-cache that gets updated with each write. It doesn't
catch every possible failure but it does catch some.

Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2014-01-27 12:47:42 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.