You would need some sort of allocation table for the journal (wal or rollback) and on a rollback commit or a wal checkpoint the allocation would need to be cleared (or maybe some "in use" bit cleared) to show that the pages were now free to be re-used.
The additional data stored with rollback journals (page number before and checksum after) and wals (wal frame before) would also need to be implemented else where and thereofre add extra logic. It sounds doable but more complex. Paul www.sandersonforensics.com skype: r3scue193 twitter: @sandersonforens Tel +44 (0)1326 572786 http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit -Forensic Toolkit for SQLite email from a work address for a fully functional demo licence On 24 February 2016 at 15:46, Igor Tandetnik <igor at tandetnik.org> wrote: > On 2/24/2016 10:08 AM, Stephen Chrzanowski wrote: >> >> IMO, all that, plus the fact that you have an easy roll back mechanism. >> Anything that needs to be put in the database is external to the pristine >> database. Lock the database with a transaction, fill up the journal, the >> power goes out, your pristine database isn't touched. > > > Rollback journal works the other way round. New data is written to database > file; previous content of overwritten pages is copied to journal file. > Committing a transaction is fast - simply delete the journal. Rolling back > (e.g. after power failure) means copying original pages from the journal > back to the database file. > > In the world you describe - how would you implement committing a > transaction? At some point, something must write to the database file; at > that point, the file is no longer "pristine". What happens if power goes out > in the middle of this? > > Note also that a typical application commits much more often than it rolls > back, so the system should be designed to make the former fast; the latter > can be slow. > -- > Igor Tandetnik > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
