On Tue, Apr 13, 2010 at 10:31 AM, Philip Martin
> "Hyrum K. Wright" <hyrum_wright_at_mail.utexas.edu> writes:
> > On Tue, Apr 13, 2010 at 7:08 AM, Philip Martin <philip_at_codematters.co.uk
> >> > [We should normally be pretty liberal with not using too-new
> >> > dependency versions, but since we've made it possible for users to
> >> > compile SQLite directly into Subversion, I think we can reasonably
> >> > make an exception in its case.]
> >> Can we do that for 1.6? Most distributions probably use the system
> >> SQLite and it won't be new enough.
> > I'd have to check, but I believe the "compile as part of Subversion"
> > capability is present in 1.6.x.
> I meant that distributions will be unhappy with a "fix" that requires
> them to use an embedded sqlite. They will also be unhappy if we force
> them to upgrade to a newer version of sqlite.
Agreed. Bumping the minimum version in a patch release is not very distro
> >> > The rep sharing cache is just a cache, and can be truncated or
> >> > deleted without impact on the correctness of the system.
> >> That's a way to fix a corrupt hotcopy but I don't think it prevents
> >> the corruption.
> > What kind of corruption are we talking about? The file gets corrupted
> > isn't recognized by SQLite as a valid database? It sees the file is a
> > database, but doesn't contain some rows? The data contained in the
> > data is wrong?
> One SQLite recommendation is a lock that excludes writers during the
> copy (http://www.sqlite.org/backup.html). I think that means that
> copies made while a write is in progress are undefined. The result
> probably depends on the platform, the size of the database, the type
> of disk caching and the phase of the moon.
Sure, but do we know what possible failure modes even are? *That's* the
question that needs to be answered, before we start thinking about ways to
fix things. In each of the modes mentioned above, the consequences are
different, and the fixes (if any) would be different.
Received on 2010-04-13 17:36:03 CEST