Rollback unnecessarily acquires dict_operation_lock for every row

InnoDB transaction rollback includes an unnecessary work-around for a data corruption bug that was fixed by me in MySQL 5.6.12. By acquiring and releasing dict_operation_lock in shared mode, row_undo() hopes to prevent the table from being dropped while the undo log record is being rolled back. But, thanks to the fix, the rollback is guaranteed to be protected by transactional locks (table IX lock, in addition to implicit or explicit exclusive locks on the records that had been modified).

In one test case for which I analyzed rr replay, this unnecessary contention on dict_operation_lock seems to slow down the rollback of a CREATE…SELECT statement. As mentioned in MDEV-21602, the error handling of CREATE…SELECT would internally invoke DROP TABLE before rolling back the changes, and that DROP TABLE would invoke another work-around in InnoDB, the background DROP TABLE queue. Because that background operation would periodically acquire dict_operation_lock in exclusive mode, it would seriously slow down any rollback operation.

While the root cause of the problem is to be addressed in MDEV-21602, unnecessary acquisitions of the known contention point dict_operation_lock should be removed. Another reason for such acquisitions is FOREIGN KEY operations, to be addressed in MDEV-21175.