Fix ProgressIndication data race on cancelQuery()

This commit is contained in:
serxa 2024-08-29 20:37:07 +00:00
parent a7d0a5991e
commit f5a88171a6
2 changed files with 14 additions and 5 deletions

View File

@ -34,13 +34,16 @@ bool ProgressIndication::updateProgress(const Progress & value)
void ProgressIndication::resetProgress()
{
watch.restart();
progress.reset();
show_progress_bar = false;
written_progress_chars = 0;
write_progress_on_update = false;
{
std::lock_guard lock(progress_mutex);
progress.reset();
show_progress_bar = false;
written_progress_chars = 0;
write_progress_on_update = false;
}
{
std::lock_guard lock(profile_events_mutex);
watch.restart();
cpu_usage_meter.reset(getElapsedNanoseconds());
hosts_data.clear();
}
@ -90,6 +93,8 @@ ProgressIndication::MemoryUsage ProgressIndication::getMemoryUsage() const
void ProgressIndication::writeFinalProgress()
{
std::lock_guard lock(progress_mutex);
if (progress.read_rows < 1000)
return;
@ -271,6 +276,8 @@ void ProgressIndication::writeProgress(WriteBufferFromFileDescriptor & message)
void ProgressIndication::clearProgressOutput(WriteBufferFromFileDescriptor & message)
{
std::lock_guard lock(progress_mutex);
if (written_progress_chars)
{
written_progress_chars = 0;

View File

@ -115,6 +115,8 @@ private:
/// It is possible concurrent access to the following:
/// - writeProgress() (class properties) (guarded with progress_mutex)
/// - hosts_data/cpu_usage_meter (guarded with profile_events_mutex)
///
/// It is also possible to have more races if query is cancelled, so that clearProgressOutput() is called concurrently
mutable std::mutex profile_events_mutex;
mutable std::mutex progress_mutex;