wrong singleflight implementation for stats' syncload #52294
Labels
affects-6.5
This bug affects the 6.5.x(LTS) versions.
affects-7.1
This bug affects the 7.1.x(LTS) versions.
affects-7.5
This bug affects the 7.5.x(LTS) versions.
report/customer
Customers have encountered this bug.
severity/major
sig/planner
SIG: Planner
type/bug
The issue is confirmed as a bug.
Comments
winoros
added
type/bug
ti-chi-bot
bot
added
may-affects-5.4
winoros
removed
may-affects-5.4
13 tasks
This was referenced Apr 7, 2024
|
/found customer |
1 similar comment
|
/found customer |
hawkingrei
pushed a commit
to hawkingrei/tidb
that referenced
this issue
Jul 1, 2024
13 tasks
winoros
pushed a commit
to winoros/tidb
that referenced
this issue
Aug 28, 2024
Merged
13 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
We use the
setWorkingfor sync load's duplicate task detection.It will return a boolean value directly after it finds duplicates.
And we can see that the
writeToResultChanalso returns directly by writing an ok result to theresultCh.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.
The text was updated successfully, but these errors were encountered: