-
Notifications
You must be signed in to change notification settings - Fork 4k
backup: ValidateEndTimeAndTruncate now supports compacted backups with rev history #158709
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
backup: ValidateEndTimeAndTruncate now supports compacted backups with rev history #158709
Conversation
…h rev history Previously, the logic in `ValidateEndTimeAndTruncate` assumed that for a revision history backup tree, there would be no compacted backups. This patch teaches the function to now work with trees that contain both revision history backups and compacted backups. The logic works as such: 1. Compacted backups that cover the requested AOST (but do not have a matching end time) are elided. 2. Any preceding compacted backups will still be included and its component backups elided. This patch is part of a larger effort to fully support compactions in revision history trees. Informs: cockroachdb#158696 Release note: None
fb2e490 to
12a500e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR enhances the ValidateEndTimeAndTruncate function to properly handle revision history backup trees that contain compacted backups. Previously, the function assumed revision history backup trees would not contain compacted backups. The new implementation intelligently handles mixed trees by eliding compacted backups that cover the requested time but don't match its end time exactly, while retaining preceding compacted backups that can be used in the restore operation.
Key changes:
- Modified
ValidateEndTimeAndTruncateto continue searching through the backup chain when encountering non-revision history backups (e.g., compacted backups), rather than failing immediately - Added new
elideCompactedBackupsForRevisionHistoryfunction to selectively remove compacted backups that cannot be used for the requested restore time - Updated
elideSkippedLayerssignature to accept the requested end time, enabling proper filtering of compacted backups in revision history restores
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| pkg/backup/backupinfo/manifest_handling.go | Implements core logic changes to support compacted backups in revision history trees, including new helper function and improved error messages. Also fixes spelling error ("fucntion" → "function"). |
| pkg/backup/backupinfo/manifest_handling_test.go | Adds comprehensive test coverage for various scenarios involving compacted backups in revision history trees, including edge cases with multiple compactions and different AOST positions. Test names abbreviated for consistency. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Since manifests are sorted by end time ascending, once we reach a backup | ||
| // whose end time is less than the requested end time, we can stop. No | ||
| // subsequent backups will cover. |
Copilot
AI
Dec 5, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nitpick] The comment could be clearer. "Subsequent backups" is ambiguous when iterating backwards. Consider: "Since manifests are sorted by end time ascending and we're iterating backwards, once we reach a backup whose end time is less than the requested end time, we can stop. All remaining backups (with lower indices) will have even earlier end times and cannot cover the requested time."
| // Since manifests are sorted by end time ascending, once we reach a backup | |
| // whose end time is less than the requested end time, we can stop. No | |
| // subsequent backups will cover. | |
| // Since manifests are sorted by end time ascending and we're iterating backwards, | |
| // once we reach a backup whose end time is less than the requested end time, we can stop. | |
| // All remaining backups (with lower indices) will have even earlier end times and cannot cover the requested time. |
|
Holding off on merging this PR until after branch cut. |
Previously, the logic in
ValidateEndTimeAndTruncateassumed that for a revision history backup tree, there would be no compacted backups. This patch teaches the function to now work with trees that contain both revision history backups and compacted backups. The logic works as such:This patch is part of a larger effort to fully support compactions in revision history trees.
Informs: #158696
Release note: None