On Wed, Mar 30, 2011 at 8:53 AM, Simon Slavin <[email protected]> wrote: > On 30 Mar 2011, at 1:46pm, Mikael wrote: >> If yes, we have the solution needed already now - app/OS crashes won't crash >> the database, and rsync backups will create working backups even if made >> during checkpoints. > > But killing the power (or pulling out the hard disk connector) while SQLite > is writing to the disk will always cause corruption, no matter what you're > doing. No matter how many components you double for fault-tolerance, you > still end up with one file written to one hard disk.
I thought the whole point of a journal was to make it possible to recover from crashed transactions. Recovery from power failures is critical. It doesn't matter so much whether recovery is handled by rolling back the affected transaction or rolling it forwards. I think the correct statement to make is that some hardware failures produce corruption, failures such as HDD failures to flush caches as requested by the OS, or corruption on disk. These kinds of failures there's nothing that can be done about from SQLite3. > SQLite has its own rescuing procedure. When you issue _open() SQLite checks > for an indication that the database was not closed neatly. For instance, it > looks for log files which should exist only if _close() was not called, and > checks other signs in the database for half-written transactions. If it sees > anything amiss it does its best to restore the database to a fit state before > it returns from the _open() call. Right, so... this contradicts your first statement above. Note that the first statement above is an indictment of SQLite3 -- no one should want it to be true, and if it is, then you should want to see it fixed. If that statement is wrong, then that needs to be clarified. Nico -- _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
