Ensure tmp files cleaned up when compaction disabled #8562
Merged
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.
Required for all non-trivial PRs
Fix for #8559.
#8559 occurs most commonly in testing when compactions that are in-progress are interrupted by the removal of data.
DROP MEASUREMENT
tends to trigger the issue. The interruption leaves.tsm.tmp
files within shard directories.Whilst we do have compaction logic to deal with interruptions, the current logic works by attempting to create
.tsm.tmp
files and, when that fails due to the file already existing, assume that another compaction is in progress. The latter compaction then bails out and complains that a.tsm.tmp
file already exists (really it's assuming that another compaction goroutine is currently taking care of the compaction).In two specific points in the compaction logic it's possible to trigger the situation where the
.tsm.tmp
files are left around but other compaction goroutines should not treat this as an on-going compaction. In these cases we remove thetsm.tmp
files.