[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] Database corruption on Linux ext3
From:       Scott Hess <shess () google ! com>
Date:       2010-07-14 5:04:23
Message-ID: AANLkTik9YSgBl57W3qvAtdGBF0z3f3b6SFAT_g0SY8ca () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jul 13, 2010 at 10:03 PM, Scott Hess <shess@google.com> wrote:
> On Tue, Jul 13, 2010 at 8:24 PM, Simon Slavin <slavins@bigfraud.org> wrote:
>> It might be useful to figure out whether we're aiming for
>> detection or correction.  By 'correction' I don't mean recovery
>> of all information, I mean restoring the database to some state
>> it was in just after a COMMIT took effect.  There's no point in
>> implementing a detection system if the users consider "This
>> database is corrupt" something worth complaining about.  On the
>> other hand, implementing a correction system may well slow down
>> every write operation and perhaps '_open' too.  It's not worth
>> doing that if slowing down SQLite will decrease usability.
>
> The best case is a system where corruption cannot happen.  Since
> that's clearly impossible ...
>
> Second-best would be an ability to rollback to a priori valid state.

[Sigh, did not mean some whizzy technical term, there.  Meant "a prior
valid state."]

-scott
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[prev in list] [next in list] [prev in thread] [next in thread]