On Mon, Feb 6, 2012 at 1:20 PM, Roger Binns <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/02/12 09:11, Nico Williams wrote: >> A checksum per-row is certainly a valuable thing at the layer above the >> RDBMS since it allows for integrity checking above the RBDMS, and in an >> RBDMS-independent manner. > > It doesn't actually help that much since it is only over a portion of the > database content. While it will catch an individual row being corrupted > it will not catch the btree that points to the table rows being corrupted.
Indeed, but if you'd do integrity protection at the application layer then surely you'd have have a backup/restore strategy to deal with lower-layer corruption. > If that container is "tweaked" then it could still be sufficiently valid > but end up omitting the row so you will get wrong query results. The same > story applies to indices where a judicious tweak will not corrupt it, but > will result in the wrong rows being selected. Yes, this tends to argue that if you want row-level checksums you also want to have SQLite3 do it as in Andy's solution. However, if you're going to have SQLite3 do it I'd rather it followed the ZFS pattern of checksumming entire pages and storing the checksum with the page pointers. > It is nice that some filesystems are adding integrity protection (and in > some cases recovery), but approximately zero percent of the systems out > there running SQLite do not have the databases stored in such a configured > filesystem today. Well, one can hope. (I don't keep up with btrfs; perhaps it will mature and become common on Android devices.) Nico -- _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
