REPLACE statement has unexpected behavior in concurrent transactions

[sayJason]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

/* init */ CREATE TABLE t0(c0 DOUBLE UNIQUE);
/* init */ INSERT INTO t0(c0) VALUES (9.1);

/* tx1 */ BEGIN;
/* tx1 */ INSERT INTO t0(c0) VALUES (2.0);
/* tx1 */ REPLACE INTO t0(c0) VALUES (9.1);
/* tx2 */ BEGIN;
/* tx2 */ DELETE FROM t0;
/* tx2 */ COMMIT;
/* tx1 */ COMMIT;
/* tx1 */ SELECT * FROM t0;

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

DELETE statement is blocked (in MySQL), or the final SELECT statement returns [(2.0), (9.1)].

3. What did you see instead (Required)

The final SELECT statement returns [(2.0)].

4. What is your TiDB version? (Required)

Release Version: v6.6.0
Edition: Community
Git Commit Hash: f4ca0821fb96a2bdd37d2fb97eb26c07fc58d4e4
Git Branch: heads/refs/tags/v6.6.0
UTC Build Time: 2023-02-17 14:49:02
GoVersion: go1.19.5
Race Enabled: false
TiKV Min Version: 6.2.0-alpha
Check Table Before Drop: false
Store: tikv

[zyguan]

Thanks for your report, @sayJason . We forget to mark unchanged keys to be locked in replace, which leads to this bug.