fix: checkpoint log_size_for_flush parameter ignored due to empty WAL file list #14193
+156
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
The log_size_for_flush parameter in CreateCheckpoint() was completely non-functional. When set to a non-zero value, it should trigger a flush only when the total WAL size exceeds the threshold. Instead, flushes were never triggered regardless of WAL size, causing checkpoints to always include WAL files instead of flushing data to SST files.
This breaks the documented API contract and prevents users from controlling checkpoint behavior. Applications relying on log_size_for_flush to ensure checkpoints contain flushed SST data (for faster recovery or smaller checkpoint sizes) were silently getting WAL-based checkpoints instead.
Root Cause
In WalManager::GetSortedWalFiles(), when called with include_archived=false, the function returned early without copying the live WAL files to the output vector:
This caused GetLiveFilesStorageInfo() to calculate WAL size as 0, so the condition 0 < log_size_for_flush was always true, skipping the flush.
Fix
Return the live WAL files before the early return when include_archived=false: