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

Rollback unnecessarily acquires dict_operation_lock for every row

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

          blocks

          Task - A task that needs to be done. MDEV-24258 Merge dict_sys.mutex into dict_sys.latch

          • Major - Major loss of function.
          • Closed
          causes

          Bug - A problem which impairs or prevents the functions of the product. MDEV-23514 SEGV storage/innobase/row/row0log.cc:863 in row_log_table_low

          • Major - Major loss of function.
          • Closed
          is blocked by

          Task - A task that needs to be done. MDEV-515 innodb bulk insert

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-23721 Assertion ‘node->table->is_temporary() || lock_table_has_locks(node->table)’ failed in row_undo_ins

          • Major - Major loss of function.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-21175 Remove dict_table_t::n_foreign_key_checks_running from InnoDB

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-21602 CREATE TABLE…PRIMARY KEY…SELECT workaround causes DROP TABLE to ignore locks

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-24324 Having an active XA transaction in THD:cleanup will release MDL locks too early.

          • Major - Major loss of function.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. MDEV-25506 Atomic DDL: .frm file is removed and orphan InnoDB tablespace is left behind upon crash recovery

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-25919 InnoDB reports misleading lock wait timeout on DDL operations

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            mleich Matthias Leich added a comment -

            The RQG testing on actual 10.5+a patch for MDEV-23484 did not show unknown problems.

            mleich Matthias Leich added a comment - The RQG testing on actual 10.5+a patch for MDEV-23484 did not show unknown problems.
            marko Marko Mäkelä added a comment -

            I think that we must revert this until MDEV-23721 has been re-analyzed, and until we have a solution for online ALTER TABLE:

            10.5 6dc037a9d1af3ab56db7bf1dc69f6c46278a9224 with some changes

            		 
            #0  0x0000560d02717fe6 in row_log_allocate (trx=<optimized out>, 
                index=index@entry=0x61700000cc20, table=<optimized out>, 
                same_pk=<optimized out>, defaults=<optimized out>, 
                col_map=<optimized out>, path=<optimized out>, old_table=<optimized out>, 
                allow_not_null=<optimized out>)
            		 
                at /home/mleich/Server/bb-10.5-MDEV-23855A/storage/innobase/row/row0log.cc:3240
            		 
            #1  0x0000560d02337fff in prepare_inplace_alter_table_dict (
            		 
                ha_alter_info=ha_alter_info@entry=0x2a0b74a257b0, 
                altered_table=altered_table@entry=0x2a0b74a25d70, 
                old_table=<optimized out>, table_name=<optimized out>, 
                flags=<optimized out>, flags2=<optimized out>, 
                fts_doc_id_col=<optimized out>, add_fts_doc_id=<optimized out>, 
                add_fts_doc_id_idx=<optimized out>)
            		 
                at /home/mleich/Server/bb-10.5-MDEV-23855A/storage/innobase/handler/handler0alter.cc:6867
            		 
            #2  0x0000560d02341e1d in ha_innobase::prepare_inplace_alter_table (this=
            		 
                0x61d0007a76b8, altered_table=<optimized out>, 
                ha_alter_info=0x2a0b74a257b0)
            		 
                at /home/mleich/Server/bb-10.5-MDEV-23855A/storage/innobase/handler/ha_innodb.h:706
            		 
            …
            		 
            mysqld: /home/mleich/Server/bb-10.5-MDEV-23855A/storage/innobase/row/row0uins.cc:91: dberr_t row_undo_ins_remove_clust_rec(undo_node_t*): Assertion `!node->trx->dict_operation_lock_mode' failed.

            Here, we are starting an online ALTER TABLE operation, even though a rollback of a previous ALTER TABLE is in progress. This would be prevented by the dict_operation_lock that we removed.

            I think that the only way to fix this is to acquire an InnoDB table S lock at the start of ALTER TABLE. Also MDEV-515 will require that. Hence, this is blocked by MDEV-515.

            marko Marko Mäkelä added a comment - I think that we must revert this until MDEV-23721 has been re-analyzed, and until we have a solution for online ALTER TABLE : 10.5 6dc037a9d1af3ab56db7bf1dc69f6c46278a9224 with some changes #0 0x0000560d02717fe6 in row_log_allocate (trx=<optimized out>, index=index@entry=0x61700000cc20, table=<optimized out>, same_pk=<optimized out>, defaults=<optimized out>, col_map=<optimized out>, path=<optimized out>, old_table=<optimized out>, allow_not_null=<optimized out>) at /home/mleich/Server/bb-10.5-MDEV-23855A/storage/innobase/row/row0log.cc:3240 #1 0x0000560d02337fff in prepare_inplace_alter_table_dict ( ha_alter_info=ha_alter_info@entry=0x2a0b74a257b0, altered_table=altered_table@entry=0x2a0b74a25d70, old_table=<optimized out>, table_name=<optimized out>, flags=<optimized out>, flags2=<optimized out>, fts_doc_id_col=<optimized out>, add_fts_doc_id=<optimized out>, add_fts_doc_id_idx=<optimized out>) at /home/mleich/Server/bb-10.5-MDEV-23855A/storage/innobase/handler/handler0alter.cc:6867 #2 0x0000560d02341e1d in ha_innobase::prepare_inplace_alter_table (this= 0x61d0007a76b8, altered_table=<optimized out>, ha_alter_info=0x2a0b74a257b0) at /home/mleich/Server/bb-10.5-MDEV-23855A/storage/innobase/handler/ha_innodb.h:706 … mysqld: /home/mleich/Server/bb-10.5-MDEV-23855A/storage/innobase/row/row0uins.cc:91: dberr_t row_undo_ins_remove_clust_rec(undo_node_t*): Assertion `!node->trx->dict_operation_lock_mode' failed. Here, we are starting an online ALTER TABLE operation, even though a rollback of a previous ALTER TABLE is in progress. This would be prevented by the dict_operation_lock that we removed. I think that the only way to fix this is to acquire an InnoDB table S lock at the start of ALTER TABLE . Also MDEV-515 will require that. Hence, this is blocked by MDEV-515 .
            marko Marko Mäkelä added a comment -

            Now that the CREATE…SELECT was fixed in MDEV-25506 part 3 in MariaDB 10.6.3, it should be possible to fix this bug in 10.6.

            marko Marko Mäkelä added a comment - Now that the CREATE…SELECT was fixed in MDEV-25506 part 3 in MariaDB 10.6.3, it should be possible to fix this bug in 10.6.

            People

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

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.