Open sayJason opened 4 weeks ago
I think the UPDATE statement in transaction 2 should by blocked by the INSERT statement in transaction 1 due to the primary key, as it happened in MySQL. Could you please explain the design and implementation considerations behind this incompatibility with MySQL in TiDB?
@cfzjywxk PTAL
@sayJason Unlike MySQL, TiDB will release the relevant lock after the statement execution fails, and MySQL will retain a shared lock on the corresponding record. The behaviour is different.
@sayJason Unlike MySQL, TiDB will release the relevant lock after the statement execution fails, and MySQL will retain a shared lock on the corresponding record. The behaviour is different.
I got it. Thanks for your reply.
Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)
2. What did you expect to see? (Required)
In MySQL, the UPDATE statement in transaction 2 is blocked until transaction 1 commits. The final query returns one row [(2, 1)].
3. What did you see instead (Required)
The UPDATE statement is not blocked, and transaction 2 can be committed directly. The final query returns two rows [(1, 10), (2, 1)].
4. What is your TiDB version? (Required)