Details

    Description

      The test case is attached.
      It's a bit different from MDEV-11525, although equally ugly, the reasons and disclaimers are the same.
      This one needs to be run with --repeat=N, if it does not fail right away.

      bb-10.2-vcols b584734d242e7c56647889e5e9c97e4a11ab5e52

      #3  <signal handler called>
      #4  0x00007fc12b9aa636 in TABLE::init (this=0x7fc102cd9c70, thd=0x7fc102c16070, tl=0x7fc102c641b8) at /data/src/bb-10.2-vcols/sql/table.cc:4443
      #5  0x00007fc12b8386f9 in open_table (thd=0x7fc102c16070, table_list=0x7fc102c641b8, ot_ctx=0x7fc12c9ce070) at /data/src/bb-10.2-vcols/sql/sql_base.cc:1921
      #6  0x00007fc12b83af57 in open_and_process_table (thd=0x7fc102c16070, lex=0x7fc102c19a80, tables=0x7fc102c641b8, counter=0x7fc12c9ce158, flags=0, prelocking_strategy=0x7fc12c9ce170, has_prelocking_list=false, ot_ctx=0x7fc12c9ce070) at /data/src/bb-10.2-vcols/sql/sql_base.cc:3397
      #7  0x00007fc12b83c049 in open_tables (thd=0x7fc102c16070, options=..., start=0x7fc12c9ce128, counter=0x7fc12c9ce158, flags=0, prelocking_strategy=0x7fc12c9ce170) at /data/src/bb-10.2-vcols/sql/sql_base.cc:3910
      #8  0x00007fc12b961957 in open_tables (thd=0x7fc102c16070, tables=0x7fc12c9ce128, counter=0x7fc12c9ce158, flags=0, prelocking_strategy=0x7fc12c9ce170) at /data/src/bb-10.2-vcols/sql/sql_base.h:236
      #9  0x00007fc12b977def in mysql_alter_table (thd=0x7fc102c16070, new_db=0x7fc102c647c0 "test", new_name=0x0, create_info=0x7fc12c9cfa50, table_list=0x7fc102c641b8, alter_info=0x7fc12c9cf9a0, order_num=0, order=0x0, ignore=false) at /data/src/bb-10.2-vcols/sql/sql_table.cc:8615
      #10 0x00007fc12b9efa23 in Sql_cmd_alter_table::execute (this=0x7fc102c648e0, thd=0x7fc102c16070) at /data/src/bb-10.2-vcols/sql/sql_alter.cc:324
      #11 0x00007fc12b8b2168 in mysql_execute_command (thd=0x7fc102c16070) at /data/src/bb-10.2-vcols/sql/sql_parse.cc:6116
      #12 0x00007fc12b8b6a44 in mysql_parse (thd=0x7fc102c16070, rawbuf=0x7fc102c64088 "ALTER TABLE `CC` ADD KEY rkr_index_1 ( `col_varchar_nokey` )", length=60, parser_state=0x7fc12c9d0dd0, is_com_multi=false, is_next_command=false) at /data/src/bb-10.2-vcols/sql/sql_parse.cc:7790
      #13 0x00007fc12b8a4794 in dispatch_command (command=COM_QUERY, thd=0x7fc102c16070, packet=0x7fc102e21071 "ALTER TABLE `CC` ADD KEY rkr_index_1 ( `col_varchar_nokey` )", packet_length=60, is_com_multi=false, is_next_command=false) at /data/src/bb-10.2-vcols/sql/sql_parse.cc:1799
      #14 0x00007fc12b8a316e in do_command (thd=0x7fc102c16070) at /data/src/bb-10.2-vcols/sql/sql_parse.cc:1359
      #15 0x00007fc12b9ea77a in do_handle_one_connection (connect=0x7fc1284754b0) at /data/src/bb-10.2-vcols/sql/sql_connect.cc:1354
      #16 0x00007fc12b9ea507 in handle_one_connection (arg=0x7fc1284754b0) at /data/src/bb-10.2-vcols/sql/sql_connect.cc:1260
      #17 0x00007fc12bd2670c in pfs_spawn_thread (arg=0x7fc115fe7770) at /data/src/bb-10.2-vcols/storage/perfschema/pfs.cc:1862
      #18 0x00007fc12aeda0a4 in start_thread (arg=0x7fc12c9d2300) at pthread_create.c:309
      #19 0x00007fc128e8787d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
      

      Attachments

        Issue Links

          Activity

            Also reproducible on bb-10.2-monty as of 349d69e2e

            elenst Elena Stepanova added a comment - Also reproducible on bb-10.2-monty as of 349d69e2e

            I don't seem to be able to repeat it in the latest bb-10.2-serg (as of 8884b88a131)

            serg Sergei Golubchik added a comment - I don't seem to be able to repeat it in the latest bb-10.2-serg (as of 8884b88a131)

            It disappeared from bb-10.2-serg starting from this revision:

            commit 8884b88a131201caee965ddbe3d43d392c44d1e3
            Author: Sergei Golubchik <serg@mariadb.org>
            Date:   Mon Feb 6 23:52:47 2017 +0100
             
                MDEV-11640 gcol.gcol_select_myisam fails in buildbot on Power
                
                JOIN_CACHE's were initialized in  check_join_cache_usage()
                from make_join_readinfo(). After that make_join_readinfo() was looking
                whether it's possible to use keyread. Later, after make_join_readinfo(),
                optimizer decided whether to use filesort. And even later, at the
                execution time, from join_read_first(), keyread was actually enabled.
                
                The problem is, that if a query uses a vcol, base columns that it
                depends on are automatically added to the read_set - because they're
                needed to calculate the vcol. But if we're doing keyread, vcol is taken
                from the index, not calculated, and base columns do not need to  be
                in the read set (even should not be - as they aren't getting values).
                
                The bug was that JOIN_CACHE used read_set with base columns,
                they were not read because of keyread, so it was caching garbage.
                
                So read_set is only known after the keyread was decided. And after the
                filesort was decided, as filesort doesn't use keyread. But
                check_join_cache_usage() needs to be done in make_join_readinfo(),
                as the code below depends on these checks,
                
                Fix: keep JOIN_CACHE checks where they were, but move initialization
                down to the very end of JOIN::optimize_inner. If keyread was enabled,
                update the read_set to include only columns that are part of the index.
                Copy the keyread logic from join_read_first() to happen at optimize time.
            

            elenst Elena Stepanova added a comment - It disappeared from bb-10.2-serg starting from this revision: commit 8884b88a131201caee965ddbe3d43d392c44d1e3 Author: Sergei Golubchik <serg@mariadb.org> Date: Mon Feb 6 23:52:47 2017 +0100   MDEV-11640 gcol.gcol_select_myisam fails in buildbot on Power JOIN_CACHE's were initialized in check_join_cache_usage() from make_join_readinfo(). After that make_join_readinfo() was looking whether it's possible to use keyread. Later, after make_join_readinfo(), optimizer decided whether to use filesort. And even later, at the execution time, from join_read_first(), keyread was actually enabled. The problem is, that if a query uses a vcol, base columns that it depends on are automatically added to the read_set - because they're needed to calculate the vcol. But if we're doing keyread, vcol is taken from the index, not calculated, and base columns do not need to be in the read set (even should not be - as they aren't getting values). The bug was that JOIN_CACHE used read_set with base columns, they were not read because of keyread, so it was caching garbage. So read_set is only known after the keyread was decided. And after the filesort was decided, as filesort doesn't use keyread. But check_join_cache_usage() needs to be done in make_join_readinfo(), as the code below depends on these checks, Fix: keep JOIN_CACHE checks where they were, but move initialization down to the very end of JOIN::optimize_inner. If keyread was enabled, update the read_set to include only columns that are part of the index. Copy the keyread logic from join_read_first() to happen at optimize time.

            People

              serg Sergei Golubchik
              elenst Elena Stepanova
              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.