-
Notifications
You must be signed in to change notification settings - Fork 6k
Closed
Labels
affects-6.5This bug affects the 6.5.x(LTS) versions.This bug affects the 6.5.x(LTS) versions.affects-7.1This bug affects the 7.1.x(LTS) versions.This bug affects the 7.1.x(LTS) versions.affects-7.5This bug affects the 7.5.x(LTS) versions.This bug affects the 7.5.x(LTS) versions.report/customerCustomers have encountered this bug.Customers have encountered this bug.severity/majorsig/plannerSIG: PlannerSIG: Plannertype/bugThe issue is confirmed as a bug.The issue is confirmed as a bug.
Description
Bug Report
We use the setWorking
for sync load's duplicate task detection.
It will return a boolean value directly after it finds duplicates.
And we can see that the writeToResultChan
also returns directly by writing an ok result to the resultCh
.
So the duplicated task will directly return without waiting for the executing one to finish.
As a result, if there are two TiDB nodes and we run sysbench's select_random_points with more than 2 threads, we will find out the following slow query:
The sync load doesn't timeout but we still have the SQLs executed without stats.
Such a slow query would disappear if the thread number is equal to or less than 2.
Metadata
Metadata
Assignees
Labels
affects-6.5This bug affects the 6.5.x(LTS) versions.This bug affects the 6.5.x(LTS) versions.affects-7.1This bug affects the 7.1.x(LTS) versions.This bug affects the 7.1.x(LTS) versions.affects-7.5This bug affects the 7.5.x(LTS) versions.This bug affects the 7.5.x(LTS) versions.report/customerCustomers have encountered this bug.Customers have encountered this bug.severity/majorsig/plannerSIG: PlannerSIG: Plannertype/bugThe issue is confirmed as a bug.The issue is confirmed as a bug.