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

DB_TRX_ID is not actually being reset when the history is removed

Details

    Description

      The purpose of MDEV-12288 is to reset the DB_TRX_ID column when the history is being removed. This is not taking place:

      --source include/have_innodb.inc
      CREATE TABLE t1(a INT PRIMARY KEY, b INT NOT NULL) ENGINE=InnoDB;
      INSERT INTO t1 VALUES(1,2),(3,4);
      UPDATE t1 SET b=-3 WHERE a=3;
      # Initiate a full purge, which should reset all DB_TRX_ID.
      SET GLOBAL innodb_fast_shutdown=0;
      --source include/shutdown_mysqld.inc
      

      After running this test, the t1.ibd file page 3 will contain nonzero DB_TRX_ID values.

      Attachments

        Issue Links

          Activity

            marko Marko Mäkelä added a comment - bb-10.3-marko

            jplindst, please run innodb.innodb_bug14147491 in the branch. It seems that some follow-up fix for MDEV-12253 is needed, so that the server will not crash when flagging a page corrupted.
            I pushed a follow-up adjustment for some test failures, including a workaround for the innodb.innodb_14147491 failure.
            It looks like some code changes will be necessary, because the system columns in two records are not being reset in innodb.table_flags.

            marko Marko Mäkelä added a comment - jplindst , please run innodb.innodb_bug14147491 in the branch. It seems that some follow-up fix for MDEV-12253 is needed, so that the server will not crash when flagging a page corrupted. I pushed a follow-up adjustment for some test failures, including a workaround for the innodb.innodb_14147491 failure. It looks like some code changes will be necessary, because the system columns in two records are not being reset in innodb.table_flags.

            It turned out that some undo log records were being omitted from the purge queue.
            Because of this, among other things, the history for the SYS_DATAFILES and SYS_FOREIGN_COLS records in SYS_TABLES was not being reset. The records were being skipped, even though the records for SYS_TABLESPACES or SYS_FOREIGN (by the same transactions) were buffered for purge.

            marko Marko Mäkelä added a comment - It turned out that some undo log records were being omitted from the purge queue . Because of this, among other things, the history for the SYS_DATAFILES and SYS_FOREIGN_COLS records in SYS_TABLES was not being reset. The records were being skipped, even though the records for SYS_TABLESPACES or SYS_FOREIGN (by the same transactions) were buffered for purge.

            Last commit ok to push, the first one still has FIXME comment, has the code review done ?

            jplindst Jan Lindström (Inactive) added a comment - Last commit ok to push, the first one still has FIXME comment, has the code review done ?

            There is one outstanding FIXME in the first commit: Carefully review the code to determine if the comment that we are removing from trx_purge_free_segment() is bogus, and if it is actually safe to remove the TRX_UNDO_DEL_MARKS field.
            I did not observe a test failure related to this, but I do need to review this. We definitely do not want to have purge accessing a stale or freed undo log page.

            All other FIXME comments have been addressed in subsequent commits to bb-10.3-marko. I will squash these commits once bb-10.3-marko is green.
            The final push to 10.3 will consist of two commits:

            1. the first 3 commits squashed together (excluding the innodb.innodb_bug14147491 changes)
            2. innodb.innodb_bug14147491 and encryption test workarounds for MDEV-13542 Crashing on a corrupted page is unhelpful
            marko Marko Mäkelä added a comment - There is one outstanding FIXME in the first commit: Carefully review the code to determine if the comment that we are removing from trx_purge_free_segment() is bogus, and if it is actually safe to remove the TRX_UNDO_DEL_MARKS field. I did not observe a test failure related to this, but I do need to review this. We definitely do not want to have purge accessing a stale or freed undo log page. All other FIXME comments have been addressed in subsequent commits to bb-10.3-marko. I will squash these commits once bb-10.3-marko is green. The final push to 10.3 will consist of two commits: the first 3 commits squashed together (excluding the innodb.innodb_bug14147491 changes) innodb.innodb_bug14147491 and encryption test workarounds for MDEV-13542 Crashing on a corrupted page is unhelpful

            ok to push.

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

            Note for benchmarks: implemented in commit 92f9be4, reference should be the commit immediately before f4b379d. Workload shall include read-only and read/write TRX. Possibly some queries using secondary indexes.

            axel Axel Schwenke added a comment - Note for benchmarks: implemented in commit 92f9be4, reference should be the commit immediately before f4b379d. Workload shall include read-only and read/write TRX. Possibly some queries using secondary indexes.

            People

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