fix(storage): avoid collecting vacuum2 result files - #20419
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9e6ec9ff95
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
|
Codex Review: Didn't find any major issues. What shall we delve into next? Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/
Summary
vacuum2previously accumulated every deleted block, index, segment, and snapshot path in aVec<String>, even when invoked throughCALL system$fuse_vacuum2(...), where the result was discarded. This made peak memory grow with the total number of deleted files.This PR:
Result<Vec<String>>toResult<()>BlockGcStatsSELECT * FROM fuse_vacuum2(...)return zero rows instead of per-file pathsThe disabled fake-time harness (
8_faked_time_prepare/9_faked_time) and its dead CI action/script are removed. Its useful coverage now runs in the normal Rust unit-test CI: deterministic retention-cutoff boundary tests plus an EE integration test that persists a middle-snapshot LVT and verifiesrespect_flash_back=trueselects that snapshot as the GC root.Tests
Type of change
The behavior change is limited to callers that consume per-file rows from
SELECT * FROM fuse_vacuum2(...); the documented operationalCALL system$fuse_vacuum2(...)path continues to report success without file details.AI assistance
This change is