add index can not be canceled timely
- Dominant language
- Go
- Stars
- 40.5k
- Forks
- 6.2k
- PR merge metrics
- PR metrics pending
Description
## Bug Report
Please answer these questions before submitting your issue. Thanks!
### 1. Minimal reproduce step (Required)
`func (dc *ddlCtx) handleRangeTasks` is executed on a single goroutine. There's a loop that process 1024 (`backfillTaskChanSize`) tasks. And each task has a network RPC to adjust end key
https://github.com/pingcap/tidb/blob/d7ce2f2faa1da3177a0f0a7e825f6e8fccd13ec8/ddl/backfilling.go#L505-L511
In the log, it costs 6 seconds to finish one loop
```
[2024/10/12 20:22:01.257 +08:00] [INFO] [backfilling.go:511] ["[ddl] send range task to workers, change end key"] ...
...
[2024/10/12 20:22:06.922 +08:00] [INFO] [backfilling.go:511] ["[ddl] send range task to workers, change end key"] ...
```
So 6 second * 1024 = 1.7h is needed to finish `handleRangeTasks`, then the job cancelation can be seen
### 2. What did you expect to see? (Required)
### 3. What did you see instead (Required)
### 4. What is your TiDB version? (Required)
this is an ONCALL, the version I checked is v6.5.4
Contributor guide
Research direction
Start in ddl/backfilling.go at ddlCtx.handleRangeTasks and the referenced loop around lines 505–511. Reproduce the cancellation scenario described in the issue and trace how the 1024-task loop and network RPCs respond to cancellation. Done means cancellation is observed without waiting for the full loop to finish.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100