transaction-correctness

Turso uses WAL (Write-Ahead Logging) mode exclusively. Files: .db , .db-wal (no .db-shm - Turso uses in-memory WAL index) Transfers WAL content back to main DB. Checkpoint types: SQLite uses a shared memory file ( -shm ) for WAL index. Turso does not - it uses in-memory data structures ( frame_cache hashmap, atomic read marks) since multi-process access is not supported. On crash: Key files: Per-Connection (private): Shared across connections: - Writer appends frames (page data) to WAL file (sequential I/O) - COMMIT = frame with non-zero db_size in header (marks transaction end) - Original DB unchanged until checkpoint - Reader acquires read mark (mxFrame = last valid commit frame) - For each page: check WAL up to mxFrame, fall back to main DB - Reader sees consistent snapshot at its read mark - PASSIVE : Non-blocking, stops at pages needed by active readers - FULL : Waits for readers, checkpoints everything - RESTART : Like FULL, also resets WAL to beginning - TRUNCATE : Like RESTART, also truncates WAL file to zero length - One writer at a time - Readers don't block writer, writer doesn't block readers - Checkpoint must stop at pages needed by active readers - First connection acquires exclusive lock - Replays valid commits from WAL - Releases lock, normal operation resumes - WAL implementation - WAL implementation - Page management, transactions - Pager - page cache, dirty...