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

innodb.instant_alter_debug fails in buildbot with wrong result

Details

    Description

      http://buildbot.askmonty.org/buildbot/builders/winx64-debug/builds/19611

      10.5 359d5f56c315cbc428e96d5d2d83d5a7

      		 
      innodb.instant_alter_debug 'innodb'      w4 [ fail ]
      		 
              Test ended at 2020-06-15 16:15:58
      		 
       
      		 
      CURRENT_TEST: innodb.instant_alter_debug
      		 
      --- D:/winx64-debug/build/src/mysql-test/suite/innodb/r/instant_alter_debug.result	2020-06-15 15:19:41.830087100 +0000
      		 
      +++ D:\winx64-debug\build\src\mysql-test\suite\innodb\r\instant_alter_debug.reject	2020-06-15 16:15:57.896423800 +0000
      		 
      @@ -204,7 +204,7 @@
      		 
       COMMIT;
      		 
       connection default;
      		 
       SET DEBUG_SYNC = 'now WAIT_FOR copied';
      		 
      -InnoDB		1 transactions not purged
      		 
      +InnoDB		2 transactions not purged
      		 
       INSERT INTO t1 SET a=1;
      		 
       INSERT INTO t1 SET a=2,b=3,c=4;
      		 
       SET DEBUG_SYNC = 'now SIGNAL logged';
      		 
       
      		 
      mysqltest: Result content mismatch

      Attachments

        Issue Links

          relates to

          Task - A task that needs to be done. MDEV-16678 Use MDL for innodb background threads instead of dict_operation_lock

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-16952 Introduce SET GLOBAL innodb_max_purge_lag_wait

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-17745 innodb.innodb_stats_persistent failed in buildbot with wrong result

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            This seems to occur most often on win32-debug, but also kvm-fulltest2 is failing every now and then. I think that only with an rr replay trace we could fix this. Failures are rather infrequent, about once in one or two weeks.
            Because this test seems to fail on 10.5 only while the test should be similar in 10.4 or even 10.3, MDEV-16678 could have something to do with this.

            marko Marko Mäkelä added a comment - This seems to occur most often on win32-debug, but also kvm-fulltest2 is failing every now and then. I think that only with an rr replay trace we could fix this. Failures are rather infrequent, about once in one or two weeks. Because this test seems to fail on 10.5 only while the test should be similar in 10.4 or even 10.3, MDEV-16678 could have something to do with this.
            marko Marko Mäkelä added a comment -

            I analyzed an rr replay trace for a similar failure of innodb.undo_truncate. In that trace, the history was eventually shrunk to 0, shortly before the server was killed. The test had failed with a result difference showing a history list length of 3.

            There might be no actual hang in the server, and could we merely have an overloaded system. It certainly does not help to ask the server ‘are we there yet? give me a full status report’ 10 times per second, throwing out most of the lengthy SHOW ENGINE INNODB STATUS output.

            wlad suggested that we could introduce a special SET GLOBAL variable for waiting for the purge to complete. It could be useful also for end users who want to ensure that any purge of history will complete before starting something special, such as executing a large join that is making extensive use of secondary indexes. Purge lag can really hurt such operations; see MDEV-20301.

            marko Marko Mäkelä added a comment - I analyzed an rr replay trace for a similar failure of innodb.undo_truncate . In that trace, the history was eventually shrunk to 0, shortly before the server was killed. The test had failed with a result difference showing a history list length of 3. There might be no actual hang in the server, and could we merely have an overloaded system. It certainly does not help to ask the server ‘are we there yet? give me a full status report’ 10 times per second, throwing out most of the lengthy SHOW ENGINE INNODB STATUS output. wlad suggested that we could introduce a special SET GLOBAL variable for waiting for the purge to complete. It could be useful also for end users who want to ensure that any purge of history will complete before starting something special, such as executing a large join that is making extensive use of secondary indexes. Purge lag can really hurt such operations; see MDEV-20301 .
            marko Marko Mäkelä added a comment -

            This should be fixed by MDEV-16952.

            marko Marko Mäkelä added a comment - This should be fixed by MDEV-16952 .

            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.