On 2/26/2016 4:01 AM, Rowan Worth wrote: > On 24 February 2016 at 23: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. > > > In principle this is correct, but actually the database *file* is not > immediately modified in rollback mode. Instead when a page is modified the > original contents are saved to the rollback journal, and the page is > updated *in memory*.
... until such time as the cache needs to be spilled - then it's updated in the database file. In fact, I'm pretty sure the rollback journal is not created as long as all the changes are entirely in RAM. I simplified to make the main point stand out: it is not true that the database file remains "pristine" while the transaction is in progress, and changes are written only to the journal file. Instead, to the first approximation, the opposite is true. >> Committing a transaction is fast - simply delete the journal. > > > So this is not quite true. It's only[1] at commit time that the pages > modified in memory are paged back to disk, and this concentration of I/O > makes commit relatively expensive. Yes, I again simplified so as not to distract from the main point. Essentially, commit forces spilling the cache. -- Igor Tandetnik
