pingcap / pingcap/tidb

add index can not be canceled timely

Open
#56,651 2 comments 0 reactions 0 assignees View on GitHub
affects-5.4 affects-6.1 affects-6.5 affects-7.1 affects-7.5 affects-8.1 component/ddl severity/major type/bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.