Comment 3 for bug 1323235

Lisheng,

Can you provide the details for the case of three concurrent deletions on the same row? I tried it as below and didn't observe deadlock.

session1: (unique index on u_id)
mysql>begin
mysql>delete from t1 where u_id = 9

session2 and session3, same command:
mysql>begin
mysql>delete from t1 where u_id = 9

Before session1 commit, the locks are:
session 1:
TABLE LOCK table `test`.`t1` trx id 7D7 lock mode IX
RECORD LOCKS space id 0 page no 324 n bits 72 index `idx_u_id` of table `test`.`t1` trx id 7D7 lock_mode X locks rec but not gap
RECORD LOCKS space id 0 page no 322 n bits 72 index `PRIMARY` of table `test`.`t1` trx id 7D7 lock_mode X locks rec but not gap

session2/3:
RECORD LOCKS space id 0 page no 324 n bits 72 index `idx_u_id` of table `test`.`t1` trx id 7D8 lock_mode X waiting

After session1 commit, session2 and 3 both continue with deletion of 0 row, before commit, the locks held were:
session 2/3:
3 lock struct(s), heap size 376, 1 row lock(s)
TABLE LOCK table `test`.`t1` trx id 7D9 lock mode IX
RECORD LOCKS space id 0 page no 324 n bits 72 index `idx_u_id` of table `test`.`t1` trx id 7D9 lock_mode X
RECORD LOCKS space id 0 page no 324 n bits 72 index `idx_u_id` of table `test`.`t1` trx id 7D9 lock_mode X locks gap before rec

Both session 2 and session 3 held two X locks on unique idx_u_id, but no dead lock or "not gap lock" as you suggested.