Skip to content
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

compact() should not update queue lengths if a compaction has locked the files to be compacted [Port to master] #22141

Closed
davidby-influx opened this issue Aug 9, 2021 · 0 comments · Fixed by #22235
Assignees
Labels

Comments

@davidby-influx
Copy link
Contributor

Port #22138 to the master branch

@davidby-influx davidby-influx self-assigned this Aug 9, 2021
davidby-influx added a commit that referenced this issue Aug 17, 2021
When the compaction planner runs, if it cannot acquire
a lock on the files it plans to compact, it returns a
nil list of compaction groups. This, in turn, sets the
engine statistics for compactions queues to zero,
which is incorrect. Instead, use the length of pending
files which would have been returned.

closes #22138

(cherry picked from commit 7d3efe1)

closes #22141
davidby-influx added a commit that referenced this issue Aug 17, 2021
When the compaction planner runs, if it cannot acquire
a lock on the files it plans to compact, it returns a
nil list of compaction groups. This, in turn, sets the
engine statistics for compactions queues to zero,
which is incorrect. Instead, use the length of pending
files which would have been returned.

closes #22138

(cherry picked from commit 7d3efe1)

closes #22141
davidby-influx added a commit that referenced this issue Aug 17, 2021
When the compaction planner runs, if it cannot acquire
a lock on the files it plans to compact, it returns a
nil list of compaction groups. This, in turn, sets the
engine statistics for compactions queues to zero,
which is incorrect. Instead, use the length of pending
files which would have been returned.

closes #22138

(cherry picked from commit 7d3efe1)

closes #22141
davidby-influx added a commit that referenced this issue Aug 17, 2021
When the compaction planner runs, if it cannot acquire
a lock on the files it plans to compact, it returns a
nil list of compaction groups. This, in turn, sets the
engine statistics for compactions queues to zero,
which is incorrect. Instead, use the length of pending
files which would have been returned.

closes #22138

(cherry picked from commit 7d3efe1)

closes #22141
davidby-influx added a commit that referenced this issue Aug 17, 2021
When the compaction planner runs, if it cannot acquire
a lock on the files it plans to compact, it returns a
nil list of compaction groups. This, in turn, sets the
engine statistics for compactions queues to zero,
which is incorrect. Instead, use the length of pending
files which would have been returned.

closes #22138

(cherry picked from commit 7d3efe1)

closes #22141

(cherry picked from commit 9923d2e)

closes #22142
davidby-influx added a commit that referenced this issue Aug 18, 2021
When the compaction planner runs, if it cannot acquire
a lock on the files it plans to compact, it returns a
nil list of compaction groups. This, in turn, sets the
engine statistics for compactions queues to zero,
which is incorrect. Instead, use the length of pending
files which would have been returned.

closes #22138

(cherry picked from commit 7d3efe1)

closes #22141

(cherry picked from commit 9923d2e)

closes #22142
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant