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

join_outer_innodb.test fails in 10.0-monty

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • None
    • None
    • None
    • None

    Description

      It fails like this 

      [psergey@pylon-fedora15 mysql-test]$ diff -urp r/join_outer_innodb.re{sult,ject}
      		 
      --- r/join_outer_innodb.result	2012-06-28 18:31:05.561398000 +0400
      		 
      +++ r/join_outer_innodb.reject	2013-07-03 06:48:45.835839473 +0400
      		 
      @@ -14,7 +14,7 @@ EXPLAIN
      		 
       SELECT COUNT(*) FROM t2 LEFT JOIN t1 ON t2.fkey = t1.id 
       WHERE t1.name LIKE 'A%' OR FALSE;
      		 
       id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
      		 
      -1	SIMPLE	t2	index	NULL	fkey	5	NULL	5	Using index
      		 
      +1	SIMPLE	t2	index	NULL	fkey	5	NULL	6	Using index
      		 
       1	SIMPLE	t1	eq_ref	PRIMARY	PRIMARY	4	test.t2.fkey	1	Using where
      		 
       DROP TABLE t1,t2;

      Attachments

        Issue Links

          is part of

          Task - A task that needs to be done. MDEV-3932 5.6 merge

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-26516 WSREP: Record locking is disabled in this thread, but the table being modified is not `mysql/wsrep_streaming_log`: `mysql/innodb_table_stats`

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-10003 main.range_innodb retuns a wrong number of rows in EXPLAIN

          • Major - Major loss of function.
          • Closed

          Activity

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

            I can observe the same thing in debugger on mysql-5.6.

            I am running the statement

            INSERT INTO t2 VALUES (1,1),(2,2),(3,2),(4,3),(5,3);

            and see:
            (gdb) set $q=& table->stat_n_rows
            (gdb) watch *$q
            Hardware watchpoint 5: *$q
            (gdb) c
            Continuing.
            Hardware watchpoint 5: *$q
            Old value = 0
            New value = 1
            0x0886379d in dict_table_n_rows_inc (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/include/dict0dict.ic:412
            (gdb) c
            Continuing.
            Hardware watchpoint 5: *$q
            Old value = 1
            New value = 2
            0x0886379d in dict_table_n_rows_inc (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/include/dict0dict.ic:412
            (gdb) c
            Continuing.
            Hardware watchpoint 5: *$q
            Old value = 2
            New value = 3
            0x0886379d in dict_table_n_rows_inc (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/include/dict0dict.ic:412
            (gdb) c
            Continuing.
            [Switching to Thread 0xa128bb90 (LWP 15090)]
            Hardware watchpoint 5: *$q
            Old value = 3
            New value = 4
            0x0899099d in dict_stats_update_persistent (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/dict/dict0stats.cc:2044
            (gdb) c
            Continuing.
            [Switching to Thread 0xa4fffb90 (LWP 15137)]
            Hardware watchpoint 5: *$q
            Old value = 4
            New value = 5
            0x0886379d in dict_table_n_rows_inc (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/include/dict0dict.ic:412
            (gdb) c
            Continuing.
            Hardware watchpoint 5: *$q
            Old value = 5
            New value = 6
            0x0886379d in dict_table_n_rows_inc (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/include/dict0dict.ic:412
            (gdb) c
            Continuing.

                1. At this point, the INSERT query is finished. In the client
                2. I see "Query OK, 5 rows affected"
                3. Note that the stats is 6. I suppose, if one gets a big enough table, the
                4. difference can be bigger.

            [Switching to Thread 0xa128bb90 (LWP 15090)]
            Breakpoint 4, dict_stats_update_persistent (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/dict/dict0stats.cc:2044
            (gdb) c
            Continuing.
            Hardware watchpoint 5: *$q
            Old value = 6
            New value = 5
            0x0899099d in dict_stats_update_persistent (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/dict/dict0stats.cc:2044
            (gdb)

            psergei Sergei Petrunia added a comment - I can observe the same thing in debugger on mysql-5.6. I am running the statement INSERT INTO t2 VALUES (1,1),(2,2),(3,2),(4,3),(5,3); and see: (gdb) set $q=& table->stat_n_rows (gdb) watch *$q Hardware watchpoint 5: *$q (gdb) c Continuing. Hardware watchpoint 5: *$q Old value = 0 New value = 1 0x0886379d in dict_table_n_rows_inc (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/include/dict0dict.ic:412 (gdb) c Continuing. Hardware watchpoint 5: *$q Old value = 1 New value = 2 0x0886379d in dict_table_n_rows_inc (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/include/dict0dict.ic:412 (gdb) c Continuing. Hardware watchpoint 5: *$q Old value = 2 New value = 3 0x0886379d in dict_table_n_rows_inc (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/include/dict0dict.ic:412 (gdb) c Continuing. [Switching to Thread 0xa128bb90 (LWP 15090)] Hardware watchpoint 5: *$q Old value = 3 New value = 4 0x0899099d in dict_stats_update_persistent (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/dict/dict0stats.cc:2044 (gdb) c Continuing. [Switching to Thread 0xa4fffb90 (LWP 15137)] Hardware watchpoint 5: *$q Old value = 4 New value = 5 0x0886379d in dict_table_n_rows_inc (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/include/dict0dict.ic:412 (gdb) c Continuing. Hardware watchpoint 5: *$q Old value = 5 New value = 6 0x0886379d in dict_table_n_rows_inc (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/include/dict0dict.ic:412 (gdb) c Continuing. At this point, the INSERT query is finished. In the client I see "Query OK, 5 rows affected" Note that the stats is 6. I suppose, if one gets a big enough table, the difference can be bigger. [Switching to Thread 0xa128bb90 (LWP 15090)] Breakpoint 4, dict_stats_update_persistent (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/dict/dict0stats.cc:2044 (gdb) c Continuing. Hardware watchpoint 5: *$q Old value = 6 New value = 5 0x0899099d in dict_stats_update_persistent (table=0x965cb80) at /home/psergey/dev2/mysql-5.6-ga/storage/innobase/dict/dict0stats.cc:2044 (gdb)
            psergei Sergei Petrunia added a comment -

            Wondering why mysql-5.6 doesn't have the problem with join_outer_innodb.test...
            it seems, the cause is vasil.dimov@oracle.com-20120521133620-glj6l0ntcsrz0wbl ... They added ANALYZE TABLE statements to stabilize the statistics.

            psergei Sergei Petrunia added a comment - Wondering why mysql-5.6 doesn't have the problem with join_outer_innodb.test... it seems, the cause is vasil.dimov@oracle.com-20120521133620-glj6l0ntcsrz0wbl ... They added ANALYZE TABLE statements to stabilize the statistics.
            psergei Sergei Petrunia added a comment -

            mysql 5.6's use of "-- disable_result_log" in test files was not helpful when analyzing this test failure...

            psergei Sergei Petrunia added a comment - mysql 5.6's use of "-- disable_result_log" in test files was not helpful when analyzing this test failure...
            psergei Sergei Petrunia added a comment -

            Fixed by making mtr to run the testsuite without persistent stats.

            psergei Sergei Petrunia added a comment - Fixed by making mtr to run the testsuite without persistent stats.
            marko Marko Mäkelä added a comment -

            Starting with MariaDB Server 10.6.5, we will no longer globally disable innodb_stats_persistent in all mtr tests. Instead, only a few special tests will disable statistics, adjust timeouts or whatever.

            marko Marko Mäkelä added a comment - Starting with MariaDB Server 10.6.5, we will no longer globally disable innodb_stats_persistent in all mtr tests . Instead, only a few special tests will disable statistics, adjust timeouts or whatever.

            People

              psergei Sergei Petrunia
              psergei Sergei Petrunia
              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.