Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR restores backward compatibility to read snapshots created in v1.16 that contain non-empty WAL (Write-Ahead Log) data. This addresses an edge case where upgrades from v1.16 → v1.17 → v1.18 occurred without time to write a new snapshot, leaving on-disk files with WAL data that v1.17+ cannot currently read.
Key Changes:
- Removes the assertion that WAL size must be zero when decoding snapshots
- Adds logic to process WAL frames from v1.16 snapshots by applying them to the main database pages
- Includes code formatting improvements (brace placement, line wrapping)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
It's still missing the data generation part
marco6
force-pushed
the
allow-non-empty-wal
branch
2 times, most recently
from
4540895 to
3f96621
Compare
marco6
force-pushed
the
allow-non-empty-wal
branch
from
3f96621 to
defcfc3
Compare
|
We are finally testing this PR. Moreover, testing found a bug and I added a check after it. |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
letFunny
left a comment
letFunny
left a comment
There was a problem hiding this comment.
Thanks for this Marco, it looks impeccable! My comments are only about minor things which is always a good sign.
2 participants
This PR re instantiates the ability to read snapshots with a non-empty WAL in case of an upgrade from v1.16 to v1.17 and then to v1.18 in which there wasn't time to write a new snapshot, hence the on-disk file still has a non empty wal.