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

Recovery behaves differently with DESC PK in innodb.leaf_page_corrupted_during_recovery

    XMLWordPrintable

Details

    Description

      I'm almost certain that it's not a real problem, since innodb.leaf_page_corrupted_during_recovery is a rather low-level and internals-specific test. Still, better to double-check, to ensure that we don't have some well-hidden issue upon recovery which might be not easy to reveal otherwise.

      diff --git a/mysql-test/suite/innodb/t/leaf_page_corrupted_during_recovery.test b/mysql-test/suite/innodb/t/leaf_page_corrupted_during_recovery.test
      index 92c3e2fbb08..f3ee93192ff 100644
      --- a/mysql-test/suite/innodb/t/leaf_page_corrupted_during_recovery.test
      +++ b/mysql-test/suite/innodb/t/leaf_page_corrupted_during_recovery.test
      @@ -11,7 +11,7 @@ call mtr.add_suppression("\\[ERROR\\] InnoDB: We detected index corruption");
       call mtr.add_suppression("\\[ERROR\\] (mysqld|mariadbd).*: Index for table 't1' is corrupt; try to repair it");
       call mtr.add_suppression("InnoDB: btr_pcur_open_low level: 0 table: `test`\\.`t1` index: `PRIMARY`");
       --enable_query_log
      -CREATE TABLE t1 (pk INT PRIMARY KEY, c CHAR(255))ENGINE=InnoDB STATS_PERSISTENT=0;
      +CREATE TABLE t1 (pk INT, PRIMARY KEY (pk DESC), c CHAR(255))ENGINE=InnoDB STATS_PERSISTENT=0;
       
       SET GLOBAL INNODB_LIMIT_OPTIMISTIC_INSERT_DEBUG = 2;
       
      

      preview-10.8-MDEV-13756-desc-indexes c10e10c693 with the test modified as above

      innodb.leaf_page_corrupted_during_recovery 'innodb,strict_crc32' [ fail ]
              Test ended at 2022-01-22 16:57:20
       
      CURRENT_TEST: innodb.leaf_page_corrupted_during_recovery
      mysqltest: At line 48: query 'SELECT * FROM t1 WHERE PK = 1' failed with wrong errno ER_TABLE_CORRUPT (1877): 'Table test/t1 is corrupted. Please drop the table and recreate.', instead of ER_UNKNOWN_STORAGE_ENGINE (1286)...
      

      So, if I get the difference correctly from the error log, in the "normal" execution the corruption is detected upon recovery, InnoDB reports it once and the plugin initialization aborts, while with the modified execution it starts up and only reveals corruption at a later stage.

      Attachments

        Issue Links

          Activity

            People

              marko Marko Mäkelä
              elenst Elena Stepanova
              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.