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

MariaRocks: rocksdb.type_varchar failure

Details

    Description

      rocksdb.type_varchar fails like this:

      CURRENT_TEST: rocksdb.type_varchar
      		 
      --- /home/psergey/dev-git/10.2-mariarocks/storage/rocksdb/mysql-test/rocksdb/r/type_varchar.result      2016-10-28 08:55:37.056371707 +0000
      		 
      +++ /home/psergey/dev-git/10.2-mariarocks/storage/rocksdb/mysql-test/rocksdb/r/type_varchar.reject      2016-12-02 19:14:06.552690598 +0000
      		 
      @@ -721,7 +721,7 @@
      		 
       insert into t values (1, 'abcabcabcabcabcabcabcabcabcabcabc  ');
      		 
       explain select 'email_i' as index_name, count(*) AS count from t force index(email_i);
      		 
       id     select_type     table   type    possible_keys   key     key_len ref     rows    Extra
      		 
      -1      SIMPLE  t       index   NULL    email_i 33      NULL    #       Using index
      		 
      +1      SIMPLE  t       ALL     NULL    NULL    NULL    NULL    #
      		 
       select 'email_i' as index_name, count(*) AS count from t force index(email_i);
      		 
       index_name     count
      		 
       email_i        1
      		 
      @@ -734,7 +734,7 @@
      		 
       insert into t values (1, 'a');
      		 
       explain select 'email_i' as index_name, count(*) AS count from t force index(email_i);
      		 
       id     select_type     table   type    possible_keys   key     key_len ref     rows    Extra
      		 
      -1      SIMPLE  t       index   NULL    email_i 33      NULL    #       Using index
      		 
      +1      SIMPLE  t       ALL     NULL    NULL    NULL    NULL    #
      		 
       select 'email_i' as index_name, count(*) AS count from t force index(email_i);
      		 
       index_name     count
      		 
       email_i        1

      Initially this was reported here:
      https://jira.mariadb.org/browse/MDEV-9658?focusedCommentId=87896&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-87896

      but in the current tree, I see the same field->part_of_key for both MariaDB and MySQL:

      (gdb) p tables_arg->table->field[0]->part_of_key
      		 
        warning: can't find linker symbol for virtual table for `Field' value
      		 
        $89 = {map = 3}
      		 
      (gdb) p tables_arg->table->field[1]->part_of_key
      		 
        warning: can't find linker symbol for virtual table for `Field' value
      		 
        $90 = {map = 0}

      Attachments

        Issue Links

          is part of

          Task - A task that needs to be done. MDEV-9658 Make MyRocks in MariaDB stable

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-11321 MariaRocks: type_binary_indexes, type_blob_indexes fail due to different index statistics

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            psergei Sergei Petrunia created issue -
            psergei Sergei Petrunia made changes -
            Field Original Value New Value
            psergei Sergei Petrunia added a comment - - edited

            At start of make_join_statistics:

            MariaDB:
            		 
            (gdb) p tables_list.head()->table->covering_keys
            		 
              $306 = {map = 0}
            		 
             
            		 
            MySQL:
            		 
            (gdb) p table->covering_keys
            		 
              $94 = {map = 2}

            covering_keys is initially set in setup_table_map():

            MySQL:
            		 
            (gdb) p table->s->keys_for_keyread
            		 
              $108 = {map = 3}
            		 
             
            		 
            MariaDB:
            		 
            (gdb) p table->s->keys_for_keyread
            		 
              $317 = {map = 1}

            In both cases, setup_table_map does this:

              table->covering_keys= table->s->keys_for_keyread;

            psergei Sergei Petrunia added a comment - - edited At start of make_join_statistics: MariaDB: (gdb) p tables_list.head()->table->covering_keys $306 = {map = 0}   MySQL: (gdb) p table->covering_keys $94 = {map = 2} covering_keys is initially set in setup_table_map(): MySQL: (gdb) p table->s->keys_for_keyread $108 = {map = 3}   MariaDB: (gdb) p table->s->keys_for_keyread $317 = {map = 1} In both cases, setup_table_map does this: table->covering_keys= table->s->keys_for_keyread;
            psergei Sergei Petrunia added a comment -

            keys_for_keyread is set in

            • MySQL: setup_key_part_field(), which is called from open_binary_frm(),
            • MariaDB: TABLE_SHARE::init_from_binary_frm_image()

            In both cases, this is a chunk of code like this:

                    if (field->key_length() == key_part->length &&
            		 
                        !(field->flags & BLOB_FLAG))
            		 
                    {
            		 
                      if (handler_file->index_flags(key, i, 0) & HA_KEYREAD_ONLY)
            		 
                      {
            		 
                        share->keys_for_keyread.set_bit(key);
            		 
                        field->part_of_key.set_bit(key);

            And when proceessing the email_i index from

            create table t (id int primary key, email varchar(100), KEY email_i (email(30)));

            MySQL will execute the above code for id as the second key part. MariaDB won't, because of its "keys with partially-columns are not extended" property.

            This is why the execution is different. This case is

            • not related to MyRocks
            • an edge case (how often does it happen that all key components are partial?)

            I'll just update the test result.

            psergei Sergei Petrunia added a comment - keys_for_keyread is set in MySQL: setup_key_part_field(), which is called from open_binary_frm(), MariaDB: TABLE_SHARE::init_from_binary_frm_image() In both cases, this is a chunk of code like this: if (field->key_length() == key_part->length && !(field->flags & BLOB_FLAG)) { if (handler_file->index_flags(key, i, 0) & HA_KEYREAD_ONLY) { share->keys_for_keyread.set_bit(key); field->part_of_key.set_bit(key); And when proceessing the email_i index from create table t (id int primary key, email varchar(100), KEY email_i (email(30))); MySQL will execute the above code for id as the second key part. MariaDB won't, because of its "keys with partially-columns are not extended" property. This is why the execution is different. This case is not related to MyRocks an edge case (how often does it happen that all key components are partial?) I'll just update the test result.
            psergei Sergei Petrunia made changes -
            Fix Version/s N/A [ 14700 ]
            Resolution Fixed [ 1 ]
            Status Open [ 1 ] Closed [ 6 ]
            psergei Sergei Petrunia made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 78617 ] MariaDB v4 [ 151317 ]

            People

              psergei Sergei Petrunia
              psergei Sergei Petrunia
              Votes:
              0 Vote for this issue
              Watchers:
              1 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.