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
Fix deadlock in backups #55132
Fix deadlock in backups #55132
Conversation
CurrentMetrics::BackupsThreads, | ||
CurrentMetrics::BackupsThreadsActive, | ||
num_backup_threads, | ||
num_backup_threads, |
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.
The sizes of these aux pools are not important since we allow them to free all threads.
This is an automated comment for commit 54c48df with description of existing statuses. It's updated for the latest CI running ❌ Click here to open a full report in a separate page Successful checks
|
@@ -91,6 +91,9 @@ class BackupsWorker | |||
std::unique_ptr<ThreadPool> backups_thread_pool; | |||
std::unique_ptr<ThreadPool> restores_thread_pool; | |||
|
|||
std::unique_ptr<ThreadPool> backup_async_executor_pool; |
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.
There can be also BACKUP ON CLUSTER ASYNC
command which waits BACKUP ASYNC
to be competed on the nodes of the cluster, so we need extra thread pools to do that safely. I've implemented that in #55216
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Fix potential
deadlock
in BACKUP/RESTORE query when amount of concurrently running backups/restores is larger than amount of threads in corresponding pools.