1. 20 Sep, 2018 2 commits
  2. 10 Sep, 2018 1 commit
  3. 04 Sep, 2018 2 commits
  4. 03 Sep, 2018 1 commit
  5. 31 Aug, 2018 1 commit
  6. 30 Aug, 2018 1 commit
    • Monty's avatar
      MDEV-16682 Assertion `(buff[7] & 7) == HEAD_PAGE' failed · 42f09ada
      Monty authored
      Problem was that SQL level tried to read a record with rnd_pos()
      that was already deleted by the same statement.
      In the case where the page for the record had been deleted, this
      caused an assert.
      Fixed by extending the assert to also handle empty pages and
      return HA_ERR_RECORD_DELETED for reads to deleted pages.
      42f09ada
  7. 24 Aug, 2018 1 commit
  8. 22 Aug, 2018 1 commit
    • Daniel Black's avatar
      item_cmp_type: simplier for a faster codepath · 064ba8cc
      Daniel Black authored
      The common case for this function is that both types are the same.
      
      The Item_result defination from include/mysql.h.pp is the following enum
         enum Item_result
         {
           STRING_RESULT=0, REAL_RESULT, INT_RESULT, ROW_RESULT, DECIMAL_RESULT,
           TIME_RESULT
         };
      
      The compilers aren't quite smart enough to optimize to this shortcut so
      this makes it quicker.
      
      Before the change:
      
      0000000000012730 <item_cmp_type(Item_result, Item_result)>:
         12730:       89 f0                   mov    %esi,%eax
         12732:       09 f8                   or     %edi,%eax
         12734:       74 4c                   je     12782 <item_cmp_type(Item_result, Item_result)+0x52>
         12736:       83 ff 02                cmp    $0x2,%edi
         12739:       75 0a                   jne    12745 <item_cmp_type(Item_result, Item_result)+0x15>
         1273b:       b8 02 00 00 00          mov    $0x2,%eax
         12740:       83 fe 02                cmp    $0x2,%esi
         12743:       74 3c                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
         12745:       83 ff 03                cmp    $0x3,%edi
         12748:       b8 03 00 00 00          mov    $0x3,%eax
         1274d:       74 32                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
         1274f:       83 fe 03                cmp    $0x3,%esi
         12752:       74 2d                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
         12754:       83 ff 05                cmp    $0x5,%edi
         12757:       b8 05 00 00 00          mov    $0x5,%eax
         1275c:       74 23                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
         1275e:       83 fe 05                cmp    $0x5,%esi
         12761:       74 1e                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
         12763:       83 ff 04                cmp    $0x4,%edi
         12766:       74 05                   je     1276d <item_cmp_type(Item_result, Item_result)+0x3d>
         12768:       83 ff 02                cmp    $0x2,%edi
         1276b:       75 0f                   jne    1277c <item_cmp_type(Item_result, Item_result)+0x4c>
         1276d:       b8 04 00 00 00          mov    $0x4,%eax
         12772:       83 fe 02                cmp    $0x2,%esi
         12775:       74 0a                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
         12777:       83 fe 04                cmp    $0x4,%esi
         1277a:       74 05                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
         1277c:       b8 01 00 00 00          mov    $0x1,%eax
         12781:       c3                      retq
         12782:       31 c0                   xor    %eax,%eax
         12784:       c3                      retq
      
      After, noting the short cut and the beginning of the function:
      
      0000000000012730 <item_cmp_type(Item_result, Item_result)>:
         12730:       39 f7                   cmp    %esi,%edi
         12732:       75 03                   jne    12737 <item_cmp_type(Item_result, Item_result)+0x7>
         12734:       89 f8                   mov    %edi,%eax
         12736:       c3                      retq
         12737:       83 ff 03                cmp    $0x3,%edi
         1273a:       b8 03 00 00 00          mov    $0x3,%eax
         1273f:       74 32                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
         12741:       83 fe 03                cmp    $0x3,%esi
         12744:       74 2d                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
         12746:       83 ff 05                cmp    $0x5,%edi
         12749:       b8 05 00 00 00          mov    $0x5,%eax
         1274e:       74 23                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
         12750:       83 fe 05                cmp    $0x5,%esi
         12753:       74 1e                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
         12755:       83 ff 04                cmp    $0x4,%edi
         12758:       74 05                   je     1275f <item_cmp_type(Item_result, Item_result)+0x2f>
         1275a:       83 ff 02                cmp    $0x2,%edi
         1275d:       75 0f                   jne    1276e <item_cmp_type(Item_result, Item_result)+0x3e>
         1275f:       b8 04 00 00 00          mov    $0x4,%eax
         12764:       83 fe 02                cmp    $0x2,%esi
         12767:       74 0a                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
         12769:       83 fe 04                cmp    $0x4,%esi
         1276c:       74 05                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
         1276e:       b8 01 00 00 00          mov    $0x1,%eax
         12773:       c3                      retq
      Signed-off-by: default avatarDaniel Black <daniel@linux.vnet.ibm.com>
      064ba8cc
  9. 20 Aug, 2018 1 commit
  10. 15 Aug, 2018 1 commit
    • Oleksandr Byelkin's avatar
      MDEV-15475: Assertion `!table || (!table->read_set ||... · 1b797e9e
      Oleksandr Byelkin authored
      MDEV-15475: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed on EXPLAIN EXTENDED with constant table and view
      
      Print constant ISNULL value independent.
      Fix of printing of view FRM and CREATE VIEW output
      1b797e9e
  11. 13 Aug, 2018 1 commit
  12. 11 Aug, 2018 1 commit
  13. 07 Aug, 2018 1 commit
  14. 06 Aug, 2018 1 commit
  15. 03 Aug, 2018 1 commit
  16. 31 Jul, 2018 1 commit
  17. 30 Jul, 2018 1 commit
  18. 29 Jul, 2018 1 commit
    • Oleksandr Byelkin's avatar
      Merge remote-tracking branch 'mysql/5.5' into 5.5 · fceda2da
      Oleksandr Byelkin authored
      We do not accept:
      1. We did not have this problem (fixed earlier and better)
       d982e717 Bug#27510150: MYSQLDUMP FAILS FOR SPECIFIC --WHERE CLAUSES
      2. We do not have such options (an DBUG_ASSERT put just in case)
       bbc2e37f Bug#27759871: BACKRONYM ISSUE IS STILL IN MYSQL 5.7
      3. Serg fixed it in other way in this release:
       e48d775c Bug#27980823: HEAP OVERFLOW VULNERABILITIES IN MYSQL CLIENT LIBRARY
      fceda2da
  19. 27 Jul, 2018 1 commit
  20. 25 Jul, 2018 3 commits
    • Varun Gupta's avatar
      MDEV-15454: Nested SELECT IN returns wrong results · 37dee22d
      Varun Gupta authored
      In this case we are setting the field Item_func_eq::in_eqaulity_no for the semi-join equalities.
      This helps us to remove these equalites as the inner tables are not available during parent select execution
      while the outer tables are not available during materialization phase.
      We only have it set for the equalites for the fields involved with the IN subquery
      and reset it for the equalities which do not belong to the IN subquery.
      
      For example in case of nested IN subqueries:
      
          SELECT t1.a FROM t1 WHERE t1.a IN
            (SELECT t2.a FROM t2 where t2.b IN
                (select t3.b from t3 where t3.c=27 ))
      
      there are two equalites involving the fields of the IN subquery
      
      1) t2.b = t3.b :  the field Item_func_eq::in_eqaulity_no is set when we merge the grandchild select into the child select
      2) t1.a = t2.a :  the field Item_func_eq::in_eqaulity_no is set when we merge the child select into the parent select
      
      But when we perform case 2) we should ensure that we reset the equalities in the child's WHERE clause.
      37dee22d
    • Varun Gupta's avatar
      MDEV-16751: Server crashes in st_join_table::cleanup or... · f9b43c25
      Varun Gupta authored
      MDEV-16751: Server crashes in st_join_table::cleanup or TABLE_LIST::is_with_table_recursive_reference
                  with join_cache_level>2
      
      During muliple equality propagation for a query in which we have an IN subquery, the items in the select list of the
      subquery may not be part of the multiple equality because there might be another occurence of the same field in the
      where clause of the subquery.
      So we keyuse_is_valid_for_access_in_chosen_plan function which expects the items in the select list of the subquery to
      be same to the ones in the multiple equality (through these multiple equalities we create keyuse array).
      The solution would be that we expect the same field not the same Item because when we have SEMI JOIN MATERIALIZATION SCAN,
      we use copy back technique to copies back the materialised table fields to the original fields of the base tables.
      f9b43c25
    • Igor Babaev's avatar
      MDEV-16820 Lost 'Impossible where' from query with inexpensive subquery · d567f161
      Igor Babaev authored
      This patch fixes another problem introduced by the patch for mdev-4817.
      The latter changed Item_cond::fix_fields() in such a way that it could
      call the virtual method is_expensive(). With the first its call
      the method saves the result in Item::is_expensive_cache. For all next
      calls the method returns the result from this cache. So if the item
      once was determined as expensive the method always returns true.
      For subqueries it's not good, because non-optimized subqueries always
      is considered as expensive.
      It means that the cache should be invalidated after the call of
      optimize_constant_subqueries().
      d567f161
  21. 19 Jul, 2018 1 commit
    • Igor Babaev's avatar
      MDEV-16726 Assertion `tab->type == JT_REF || tab->type == JT_EQ_REF' failed · 9cea4ccf
      Igor Babaev authored
      Due to a legacy bug in the code of make_join_statistics() detecting
      so-called constant tables could miss some of them in rare queries
      that used RIGHT JOIN. As a result these queries had execution plans
      different from the execution plans of the equivalent queries with
      LEFT JOIN.
      Besides starting from 10.2 this could trigger an assertion failure.
      9cea4ccf
  22. 16 Jul, 2018 1 commit
  23. 11 Jul, 2018 1 commit
  24. 10 Jul, 2018 1 commit
  25. 30 Jun, 2018 1 commit
    • Igor Babaev's avatar
      MDEV-16603 Crash with set join_cache_level=4 · 90cb7212
      Igor Babaev authored
      When the definition of the index used for hash join was created
      in create_hj_key_for_table() it could cause memory overwrite
      due to a bug that led to an underestimation of the number of
      the index component.
      90cb7212
  26. 27 Jun, 2018 4 commits
    • Sergey Vojtovich's avatar
      MDEV-8540 - Crash on server shutdown since 10.0.16 · 9d41dd2f
      Sergey Vojtovich authored
      For the purpose of reporting an error to error log, shutdown thread was
      attempting to access current_thd->variables.lc_messages->errmsgs->errmsgs.
      Whereas current_thd was NULL.
      
      We should log errors according to global lc_messages setting instead of
      session setting.
      9d41dd2f
    • Michael Widenius's avatar
      Fixed MDEV-16512, crashing on re-execution of failing SP · 937c1931
      Michael Widenius authored
      MDEV-16512 Server crashes in find_field_in_table_ref on 2nd
      execution of SP referring to non-existing field
      
      Problem was in the natural join code that it changed TABLE_LIST and
      Item_fields but didn't restore changed things if things goes wrong
      and was not able to re-execute after failure.
      Some of the problems could have been avoided if we would have run
      fix_fields before doing natural join transformations.
      
      Fixed by marking functions complete AFTER they had executed, instead at
      start.
      I had also to change some tests that checked if Item_fields are usable.
      
      This doesn't fix all known problems, but at least avoids some crashes.
      What should be done in the near future is to mark the statement in the SP
      as 'not re-executable' and force a reparse of it on next execution.
      
      Reviewer: Sergei Petrunia <psergey@askmonty.org>
      937c1931
    • Michael Widenius's avatar
      faef2e6a
    • Michael Widenius's avatar
      1f6a89a8
  27. 26 Jun, 2018 1 commit
  28. 20 Jun, 2018 3 commits
  29. 19 Jun, 2018 1 commit
  30. 15 Jun, 2018 1 commit
  31. 12 Jun, 2018 1 commit