On Aug 19, 2015, at 11:34 PM, Simon Slavin <slavins at bigfraud.org> wrote: > > > On 20 Aug 2015, at 6:22am, Scott Perry <numist at apple.com> wrote: > >> That said, it's possible to corrupt a database by forcing the device to >> power off (by holding the power and home buttons) while SQLite's writes are >> in flight. This is equivalent to the conditions of a kernel panic. > > This is true only if your storage subsystem (usually hard disk plus it's > driver) does not work properly, and a couple of bad coincidences happen. In > almost all situations, when SQLite next accesses the database it will notice > a journal file still exists for it and use the information in the journal > file to uncorrupt the database. > > The resulting database might or might not reflect the last transaction's > changes. It depends on precisely when power was lost. But it should not be > corrupt, and it should reflect all changes up to the end of a transaction.
If the NAND controller is interrupted by power loss or kernel panic, it is possible for a write to be partially applied to disk, a condition that SQLite cannot defend against. These conditions are extremely rare, especially in the wild, but at scale every possible error is a certainty.
