Repository navigation
A fix to WAL crash recovery. Upgrade recommended for every 0.2.0 user. The file format is unchanged, and files written by 0.2.0 open as before. Every published crate moves to 0.2.1 together.
Fixed
- Records the WAL had lost could come back after a later recovery (#508, D209).
- When: a power loss (not a process crash) while a WAL segment was starting in a reused slot. The disk had to keep part of that write (the first records) and lose the rest (the segment's header). The database then had to reopen, write little or nothing more to that WAL stream, and recover again later.
- What happened: recovery correctly ignored those records the first time. But the reopened stream reused the lost header's numbering in the same slot, so at the next recovery the old records read as new ones.
- Effect: writes that a power loss should have discarded could reappear. Their sequence numbers could also be reused by newer commits, mixing old and new data in recovery. The records that come back are only ever ones that were never synced.
- The fix: recovery now starts a reopened stream three numbers above the largest it saw (FORMAT §10.1). Nothing reads or writes differently otherwise.
Upgrading
Change nothing but the version: pigeonhole = "0.2" already resolves to 0.2.1 after a cargo update -p pigeonhole. Process crashes were never affected on 0.2.0; the exposure is a power loss during a specific WAL write. Acknowledged durable commits (GroupSync / Sync) were never lost.
Details: #508 (root cause and reproduction), D209 (the fix), #512 (main), #514 (this backport).