TxnHeartbeat may start too late if locking the first keys takes too long

[sticnarf]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

1. Begin a pessimistic transaction T1.
2. In the first write SQL, write a lot of keys such as delete * from t from a big table. To reproduce the issue, this step should take longer than 20 seconds.
3. Mutate the keys that is already locked in step 2 from another transaction T2.
4. Commit the transaction T1.

2. What did you expect to see? (Required)

Step 3 should block. T1 should commit successfully in step 4.

3. What did you see instead (Required)

Step 3 succeeds. Step 4 reports PessimisticLockNotFound.

4. What is your TiDB version? (Required)

TiDB 3.0+

[sticnarf]

The keep alive goroutine is launched after the keys are all locked.

Locking the keys may involve multiple requests and the primary key is locked first. So, after all the keys are locked, the primary lock may have been expired.

When another transaction encounters the expired locks, they can clear the locks. So before the keep alive goroutine starts, some pessimistic locks have already been removed. Therefore, the transaction will finally fail to commit.

[youjiali1995]

Fixed by tikv/client-go#261.

[github-actions]

Please check whether the issue should be labeled with 'affects-x.y' or 'backport-x.y.z',
and then remove 'needs-more-info' label.