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

main.partition_innodb fails in buildbot with wrong result

Details

    Description

      http://buildbot.askmonty.org/buildbot/builders/win32-debug/builds/14995

      10.4 11f3e2366282eb8cf1cb0062793d1020

      		 
      main.partition_innodb 'innodb'           w1 [ fail ]
      		 
              Test ended at 2019-07-24 16:28:53
      		 
       
      		 
      CURRENT_TEST: main.partition_innodb
      		 
      --- D:/win32-debug/build/src/mysql-test/main/partition_innodb.result	2019-07-24 16:10:28.471773300 +0000
      		 
      +++ D:\win32-debug\build\src\mysql-test\main\partition_innodb.reject	2019-07-24 16:28:53.693111000 +0000
      		 
      @@ -406,7 +406,7 @@
      		 
       insert into t1 values (0), (1), (2), (3);
      		 
       show table status;
      		 
       Name	Engine	Version	Row_format	Rows	Avg_row_length	Data_length	Max_data_length	Index_length	Data_free	Auto_increment	Create_time	Update_time	Check_time	Collation	Checksum	Create_options	Comment	Max_index_length	Temporary
      		 
      -t1	InnoDB	10	Dynamic	4	4096	16384	0	0	#	NULL	#	NULL	NULL	latin1_swedish_ci	NULL	partitioned		0	N
      		 
      +t1	InnoDB	10	Dynamic	5	3276	16384	0	0	#	NULL	#	NULL	NULL	latin1_swedish_ci	NULL	partitioned		0	N
      		 
       drop table t1;
      		 
       create table t1 (a int auto_increment primary key)
      		 
       engine = innodb
      		 
       
      		 
      mysqltest: Result content mismatch

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-21136 InnoDB's records_in_range estimates can be way off

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-22119 main.innodb_ext_key fails sporadically

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-33080 main.innodb_ext_key test case explain estimates 6 rows sometimes

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

          Activity

            Ascending order - Click to sort in descending order
            View 13 older comments
            psergei Sergei Petrunia added a comment -

            Sergei Petrunia, how much do you think the number of records could deviate in the tests main.partition_innodb, main.innodb_ext_key, or main.stat_tables before a different query plan could be chosen?

            No idea. There are test cases there that have secondary indexes and only a few rows. This means the difference between query plan costs could be very small.

            psergei Sergei Petrunia added a comment - Sergei Petrunia, how much do you think the number of records could deviate in the tests main.partition_innodb, main.innodb_ext_key, or main.stat_tables before a different query plan could be chosen? No idea. There are test cases there that have secondary indexes and only a few rows. This means the difference between query plan costs could be very small.
            psergei Sergei Petrunia added a comment -

            marko, If we just do ANALYZE TABLE before doing any SELECTs on the table, will this guarantee that the #rows after it is stable?

            (IIRC the regular approach of "use #rows_in_table from EITS" is not possible here as EITS estimates won't be used for partitioned tables. There's no per-partition EITS statistics and partition pruning can make whole-table estimates very bad)

            psergei Sergei Petrunia added a comment - marko , If we just do ANALYZE TABLE before doing any SELECTs on the table, will this guarantee that the #rows after it is stable? (IIRC the regular approach of "use #rows_in_table from EITS" is not possible here as EITS estimates won't be used for partitioned tables. There's no per-partition EITS statistics and partition pruning can make whole-table estimates very bad)
            marko Marko Mäkelä added a comment -

            psergei, yes, ANALYZE TABLE should produce stable results, ever since MDEV-10682 was fixed. Can you revise the affected tests accordingly?

            marko Marko Mäkelä added a comment - psergei , yes, ANALYZE TABLE should produce stable results, ever since MDEV-10682 was fixed. Can you revise the affected tests accordingly?
            knielsen Kristian Nielsen added a comment -

            Pushed to 10.4. But the test should be re-enabled in 10.5 (there's some .result update needed IIRC) before closing this bug.

            knielsen Kristian Nielsen added a comment - Pushed to 10.4. But the test should be re-enabled in 10.5 (there's some .result update needed IIRC) before closing this bug.
            psergei Sergei Petrunia added a comment - - edited

            Enabled the test in 10.5:

            commit b97f4c340ead53c42ec674da19b420e57bf40ddc
            		 
            Author: Sergei Petrunia <sergey@mariadb.com>
            		 
            Date:   Mon Dec 4 20:34:45 2023 +0300
            		 
             
            		 
                Followup for fix for MDEV-20169: enable main.partition_innodb

            psergei Sergei Petrunia added a comment - - edited Enabled the test in 10.5: commit b97f4c340ead53c42ec674da19b420e57bf40ddc Author: Sergei Petrunia <sergey@mariadb.com> Date: Mon Dec 4 20:34:45 2023 +0300   Followup for fix for MDEV-20169: enable main.partition_innodb

            People

              knielsen Kristian Nielsen
              elenst Elena Stepanova
              Votes:
              1 Vote for this issue
              Watchers:
              7 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.