mirror of
https://github.com/narrrl/proton-drive-linux.git
synced 2026-11-03 16:41:26 +01:00
nvrlandClaude Opus 4.8
e259016a00
Verified against a live install: vacuum reported "34.3 MiB freed (170.3 MiB -> 136.0 MiB), 0 WAL frame(s) checkpointed" while the WAL grew from 67 MiB to 143 MiB. Net disk use barely moved, and the frame count was zero because the checkpoint ran before the VACUUM, when there was nothing to fold. Reordering is strictly better, but the commit message should not overstate it: the live inflation happens because the daemon's other connections hold read transactions and a TRUNCATE checkpoint waits on readers, so under a busy daemon this can still move little. journal_size_limit stays the backstop -- the live WAL did fall back to its 64 MiB cap on its own afterwards. The accompanying test deliberately does not assert on WAL size or frame count. Measured both ways, a single-connection test reports frames=0 and a 0-byte WAL under either ordering, because SQLite folds the log itself without a concurrent reader to block it; an assertion there would pass on the bug and be decoration. It asserts what is reliably true instead -- that a file-backed vacuum reclaims space and leaves the database sound -- and the ordering rationale plus the residual uncertainty are documented on vacuum() itself. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JFzNQyb4TWrCRWcnegqWxY