> -----Original Message-----
> From: Markus Schaber [mailto:m.scha...@codesys.com]
> Sent: maandag 27 januari 2014 13:36
> To: Subversion Development
> Subject: AW: FSFS rep-cache validation
>
> Hi,
>
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> > Philip Martin <philip.mar...@wandisco.com> writes:
> >
> > > Stefan Fuhrmann <stefan.fuhrm...@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's suggestion: 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.
>
> To increase the backwards compatibility: Could this row be updated by a
> trigger?
Keeping backwards compatibility here would require a time machine :-)
We would have to change the database schema, which requires a format bump...
(not just for the trigger; also for the new table)
And a trigger would perform this for any file update in any revision; not
just once per revision.
If we just update it after writing all revisions (and right before the
existing sqlite transaction is committed) there should only be a single db
page update, so it should only make sqlite a very tiny bit slower. With a
trigger the intermediate state in the sqlite log would grow more than a bit
during the transaction.
Bert
