Rollback journal
A rollback journal is an undo log that preserves original database content so an incomplete transaction can be reversed.
SQLite records original page content and the database's starting size before overwriting stored pages. Recovery restores those pages and, when necessary, the original file length. [1] This differs from SQLite WAL mode, which appends changed pages and a commit record to a separate log. [4] Keeping a journal in memory does not provide crash recovery, and disabling journaling removes rollback protection. [3] Journal presence alone does not identify an incomplete transaction; SQLite checks whether the journal is hot. [2] See the comparison of recovery boundaries. [6] A disposable process-exit observation demonstrates journal retention after commit and rollback of unfinished writes; it is not a power-loss test. [7]
Relations
- related
- hot-journal, sqlite-super-journal, write-ahead-log, database-checkpoint, crash-consistency, fsync, persistence-ordering
Advantages
- Preserves before-images needed to undo changes from an interrupted transaction. [1]
Limitations
- Recovery depends on the journal remaining available and on working filesystem locks and synchronization. [2]
- Rollback-mode synchronous=FULL does not guarantee power-loss durability on every filesystem; EXTRA adds protection for DELETE-mode commits. [5]
Citations
- SQLite: Atomic Commit In SQLite
- SQLite: File Locking And Concurrency In SQLite Version 3
- SQLite: Temporary Files Used By SQLite
- SQLite: Write-Ahead Logging
- SQLite: PRAGMA synchronous
- Hesela: WAL, checkpoints and torn pages, SQLite commit scope
- Hesela: SQLite journal-lifecycle observations, measured synthetic workload and explicit limits