Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23484

Rollback unnecessarily acquires dict_operation_lock for every row

    XMLWordPrintable

    Details

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              marko Marko Mäkelä
              Reporter:
              marko Marko Mäkelä
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated: