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

Page contains nonzero PAGE_MAX_TRX_ID

Details

    Description

      The field PAGE_MAX_TRX_ID only matters in secondary index leaf pages. It was expected to be 0 on all other pages until the field is put into some other use.
      (MDEV-6076 repurposed the field in clustered index root pages for a persistent AUTO_INCREMENT value. MDEV-11369 and MDEV-11424 may repurpose it in further clustered index pages.)

      When running innodb.innodb-wl5522-debug or innodb_zip.wl5522_debug_zip with innodb_page_size=4k, an assertion in btr_page_reorganize_low() is failing:

      	/* PAGE_MAX_TRX_ID must be zero on non-leaf pages other than
      	clustered index root pages. */
      	ut_ad(recovery
      	      || page_get_max_trx_id(page) == 0
      	      || (dict_index_is_sec_or_ibuf(index)
      		  ? page_is_leaf(temp_page)
      		  : page_is_root(temp_page)));
      

      An easy fix would be to relax the assertion:

      	/* PAGE_MAX_TRX_ID must be zero on non-leaf pages other than
      	clustered index root pages. */
      	ut_ad(recovery
      	      || page_get_max_trx_id(page) == 0
      	      || dict_index_is_sec_or_ibuf(index)
      	      || page_is_root(temp_page));
      

      But I would like to study why this happens. Maybe we are not clearing PAGE_MAX_TRX_ID when splitting a secondary index leaf page.

      Attachments

        Issue Links

          Activity

            With innodb_page_size=32k and innodb_page_size=64k, also the relaxed assertion is failing for innodb.innodb-wl5522-debug, for the clustered index.
            In the clustered index the PAGE_MAX_TRX_ID field should always have been 0 until MDEV-6076 repurposed it for the root page only:

            2017-02-24 12:46:44 140590992532224 [Note] InnoDB: Phase II - Purge records from index `PRIMARY`
            2017-02-24 12:46:44 0x7fdde42b2300  InnoDB: Assertion failure in file /mariadb/server/storage/innobase/btr/btr0btr.cc line 1625
            InnoDB: Failing assertion: recovery || page_get_max_trx_id(page) == 0 || dict_index_is_sec_or_ibuf(index) || page_is_root(temp_page)
            

            marko Marko Mäkelä added a comment - With innodb_page_size=32k and innodb_page_size=64k, also the relaxed assertion is failing for innodb.innodb-wl5522-debug, for the clustered index. In the clustered index the PAGE_MAX_TRX_ID field should always have been 0 until MDEV-6076 repurposed it for the root page only: 2017-02-24 12:46:44 140590992532224 [Note] InnoDB: Phase II - Purge records from index `PRIMARY` 2017-02-24 12:46:44 0x7fdde42b2300 InnoDB: Assertion failure in file /mariadb/server/storage/innobase/btr/btr0btr.cc line 1625 InnoDB: Failing assertion: recovery || page_get_max_trx_id(page) == 0 || dict_index_is_sec_or_ibuf(index) || page_is_root(temp_page)
            marko Marko Mäkelä added a comment - bb-10.2-marko

            bb-10.2-marko rebased to latest 10.2 (fixing a result after MDEV-11995). No change to the patch.

            marko Marko Mäkelä added a comment - bb-10.2-marko rebased to latest 10.2 (fixing a result after MDEV-11995 ). No change to the patch.

            ok to push.

            jplindst Jan Lindström (Inactive) added a comment - ok to push.

            This bug impacts MDEV-6076 (persistent AUTO_INCREMENT) when using IMPORT TABLESPACE with data files on which IMPORT TABLESPACE has been used before MariaDB 10.2.6. In those cases, the AUTO_INCREMENT value will be restored to a bogus value (something that was a transaction ID in the previous IMPORT).

            marko Marko Mäkelä added a comment - This bug impacts MDEV-6076 (persistent AUTO_INCREMENT) when using IMPORT TABLESPACE with data files on which IMPORT TABLESPACE has been used before MariaDB 10.2.6. In those cases, the AUTO_INCREMENT value will be restored to a bogus value (something that was a transaction ID in the previous IMPORT).

            People

              marko Marko Mäkelä
              marko Marko Mäkelä
              Votes:
              0 Vote for this issue
              Watchers:
              2 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.