Unnecessary explicit lock acquisition during UPDATE or DELETE

In InnoDB, an INSERT will not create an explicit lock object. Instead, the inserted record is initially implicitly locked by the transaction that wrote its trx_t::id to the hidden system column DB_TRX_ID. (Other transactions would check if DB_TRX_ID is referring to a transaction that has not been committed.)

If a record was inserted in the current transaction, it would be implicitly locked by that transaction. Only if some other transaction is requesting access to the record, the implicit lock should be converted to an explicit one, so that the waits-for graph can be constructed for detecting deadlocks and lock wait timeouts.

The bug is that currently, InnoDB would convert the implicit lock to an explicit one, even if no conflict exists. Here is an example:

--source include/have_innodb.inc

CREATE TABLE t1(id INT PRIMARY KEY, a INT, b CHAR(1), UNIQUE KEY u(a,b)) ENGINE=InnoDB;

BEGIN;

INSERT INTO t1 VALUES(1,1,'a'),(2,9999,'b'),(3,10000,'c'),(4,4,'d');

DELETE FROM t1 WHERE a = 9999 AND b='b';

COMMIT;

DROP TABLE t1;

In this test, there is no conflict, and the DELETE statement should not convert the implicit lock into an explicit one. But, the function lock_rec_convert_impl_to_expl_for_trx() is being invoked during the test.