InnoDB fails to discard record lock when discarding an index page

In InnoDB, the function btr_cur_pessimistic_delete() should invoke the function lock_update_delete() before deleting the record.

InnoDB fails to do this when the entire page becomes empty and the only record in the page is deleted by btr_discard_page(). As a result of this, the transaction may keep holding explicit locks on a freed page. The scenario could involve a ROLLBACK TO SAVEPOINT of an INSERT or UPDATE.

If this freed page is soon reused by another transaction, the transaction that performed the btr_discard_page() could wrongly hold explicit locks on the records that should be owned by the other transaction, violating the Isolation property of ACID.

This bug is present in all InnoDB versions. Here is the code from MySQL 3.23.49:

	if ((page_get_n_recs(page) < 2)

	    && (dict_tree_get_page(btr_cur_get_tree(cursor))

					!= buf_frame_get_page_no(page))) {

		/* If there is only one record, drop the whole page in

		btr_discard_page, if this is not the root page */

		btr_discard_page(cursor, mtr);

		*err = DB_SUCCESS;

		ret = TRUE;

		goto return_after_reservations;	

	}

	rec = btr_cur_get_rec(cursor);

	lock_update_delete(rec);

Theoretically, this bug could explain the corruption that has been reported in MDEV-9663, especially when it occurs on a secondary index (rolling back the update of an indexed column). My comment 2017-08-24 12:46 in MDEV-9663 notes that there was corruption on unique secondary indexes. InnoDB would handle a duplicate key error by rolling back the latest row operation. It is possible that we now found an explanation to that analyzed case of MDEV-9663 corruption.