1. 04 Feb, 2013 1 commit
    • unknown's avatar
      Fix for bug MDEV-765 (LP:825075) · 0b2dc3fc
      unknown authored
      Analys:
      The cause for the wrong result was that the optimizer
      incorrectly chose min/max loose scan when it is not
      applicable. The applicability test missed the case when
      a condition on the MIN/MAX argument was OR-ed with a
      condition on some other field. In this case, the MIN/MAX
      condition cannot be used for loose scan.
      
      Solution:
      Extend the test check_group_min_max_predicates() to check
      that the WHERE clause is of the form: "cond1 AND cond2"
      where 
        cond1 - does not use min_max_column at all.
        cond2 - is an AND/OR tree with leaves in form "min_max_column $CMP$ const"
                or $CMP$ is one of the functions between, is [not] null
      
      0b2dc3fc
  2. 28 Jan, 2013 2 commits
  3. 26 Jan, 2013 1 commit
  4. 25 Jan, 2013 7 commits
  5. 24 Jan, 2013 2 commits
  6. 22 Jan, 2013 1 commit
  7. 21 Jan, 2013 4 commits
    • Igor Babaev's avatar
      Merge 5.1->5.2 · 8127e631
      Igor Babaev authored
      8127e631
    • Igor Babaev's avatar
      Merge. · 82fe8a4e
      Igor Babaev authored
      82fe8a4e
    • Igor Babaev's avatar
      Fixed bug mdev-4063 (bug #56927). · fade3647
      Igor Babaev authored
      This bug could result in returning 0 for the expressions of the form 
      <aggregate_function>(distinct field) when the system variable  
      max_heap_table_size was set to a small enough number.
      It happened because the method Unique::walk() did not support
      the case when more than one pass was needed to merge the trees
      of distinct values saved in an external file.
      
      Backported a fix in grant_lowercase.test from mariadb 5.5.
      fade3647
    • Sergei Golubchik's avatar
      MDEV-4029 SELECT on information_schema using a subquery locks up the... · 43c6953f
      Sergei Golubchik authored
      MDEV-4029 SELECT on information_schema using a subquery locks up the information_schema table due to incorrect mutexes handling
        
      Early evaluation of subqueries in the WHERE conditions on I_S.*_STATUS tables,
      otherwise the subquery on this same table will try to acquire LOCK_status twice.
      43c6953f
  8. 20 Jan, 2013 1 commit
  9. 16 Jan, 2013 2 commits
    • Igor Babaev's avatar
      Corrected the fix for bug mdev-3938. · 63afbba4
      Igor Babaev authored
      63afbba4
    • unknown's avatar
      MDEV-4056 fix. · 2255132f
      unknown authored
      The problem was that maybe_null of Item_row and its componetes was unsynced after update_used_tables() (and so pushed_cond_guards was not initialized but then requested).
      
      Fix  updates Item_row::maybe_null on update_used_tables().
      2255132f
  10. 17 Jan, 2013 2 commits
    • unknown's avatar
      MDEV-3900 Optimizer difference between MySQL and MariaDB with stored functions... · d51f96b1
      unknown authored
      MDEV-3900 Optimizer difference between MySQL and MariaDB with stored functions in WHERE clause of UPDATE or DELETE statements
      
      Analysis
      The reason for the less efficient plan was result of a prior design decision -
      to limit the eveluation of constant expressions during optimization to only
      non-expensive ones. With this approach all stored procedures were considered
      expensive, and were not evaluated during optimization. As a result, SPs didn't
      participate in range optimization, which resulted in a plan with table scan
      rather than index range scan.
      
      Solution
      Instead of considering all SPs expensive, consider expensive only those SPs
      that are non-deterministic. If an SP is deterministic, the optimizer will
      checj if it is constant, and may eventually evaluate it during optimization.
      
      d51f96b1
    • unknown's avatar
      backport of: · 8a296e6c
      unknown authored
      Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
      This fixed failing test in group_by.test
      8a296e6c
  11. 16 Jan, 2013 2 commits
    • unknown's avatar
      MDEV-3988 fix. · a716b061
      unknown authored
      Subquery turned into constant too late to be excluded from grouping list so test for constant added to the create_temp_table().
      a716b061
    • Igor Babaev's avatar
      Fixed bug mdev-3938. · f8f90aa7
      Igor Babaev authored
      The original patch with the implementation of virtual columns
      did not support INSERT DELAYED into tables with virtual columns.
      This patch fixes the problem.
      f8f90aa7
  12. 12 Jan, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4025. · 12bf6fe8
      Igor Babaev authored
      The bug could lead to a wrong estimate of the number of expected rows
      in the output of the EXPLAIN commands for queries with GROUP BY.
      This could be observed in the test case for LP bug 934348.
      12bf6fe8
  13. 11 Jan, 2013 1 commit
    • Vladislav Vaintroub's avatar
      MDEV-4020 : Make sure strmov symbol is exported by client library on Linux... · d8acafcb
      Vladislav Vaintroub authored
      MDEV-4020 : Make sure strmov symbol is exported by client library  on Linux (even if the server and libraries itself use stpcpy instead of it)
      
      It is a workaround that allows myodbc built by certain distributions' (CentOS,Fedora) to peacefully coexist with mariadb client libraries.
      The problem is that MyODBC in these distros needs strmov() to be exported by mysql client shared library, or else myodbc fails to load.
      d8acafcb
  14. 10 Jan, 2013 2 commits
  15. 09 Jan, 2013 1 commit
  16. 08 Jan, 2013 1 commit
  17. 28 Dec, 2012 1 commit
    • unknown's avatar
      MDEV-3873 & MDEV-3876 & MDEV-3912 : Wrong result (extra rows) with ALL subquery · 6f26aac9
      unknown authored
      from a MERGE view.
      
      The problem was in the lost ability to be null for the table of a left join if it
      is a view/derived table.
      
      It hapenned because setup_table_map(), was called earlier then we merged
      the view or derived.
      
      Fixed by propagating new maybe_null flag during Item::update_used_tables().
      
      Change in join_outer.test and join_outer_jcl6.test appeared because
      IS NULL reported no used tables (i.e. constant) for argument which could not be
      NULL and new maybe_null flag was propagated for IS NULL argument (Item_field)
      because table the Item_field belonged to changed its maybe_null status.
      6f26aac9
  18. 21 Dec, 2012 3 commits
  19. 19 Dec, 2012 1 commit
    • unknown's avatar
      MDEV-3928: Assertion `example' failed in Item_cache::is_expensive_processor... · e99aa91e
      unknown authored
      MDEV-3928: Assertion `example' failed in Item_cache::is_expensive_processor with a 2-level IN subquery
      
      Analysis:
      The following call stack shows that it is possible to set Item_cache::value_cached, and the relevant value
      without setting Item_cache::example.
      
      #0 Item_cache_temporal::store_packed at item.cc:8395
      #1 get_datetime_value at item_cmpfunc.cc:915
      #2 resolve_const_item at item.cc:7987
      #3 propagate_cond_constants at sql_select.cc:12264
      #4 propagate_cond_constants at sql_select.cc:12227
      #5 optimize_cond at sql_select.cc:13026
      #6 JOIN::optimize at sql_select.cc:1016
      #7 st_select_lex::optimize_unflattened_subqueries at sql_lex.cc:3161
      #8 JOIN::optimize_unflattened_subqueries at opt_subselect.cc:4880
      #9 JOIN::optimize at sql_select.cc:1554
      
      The fix is to set Item_cache_temporal::example even when the value is
      set directly by Item_cache_temporal::store_packed. This makes the
      Item_cache_temporal object consistent.
      e99aa91e
  20. 11 Dec, 2012 1 commit
  21. 07 Dec, 2012 1 commit
    • Joerg Bruehe's avatar
      Last-minute fix to 5.1.67, · d07b5f1c
      Joerg Bruehe authored
      taking a change done to main 5.1 by Dmitri Lenev.
      
      This is the original comment:
      
      > committer: Dmitry Lenev <Dmitry.Lenev@oracle.com>
      > branch nick: mysql-5.1-15954896
      > timestamp: Wed 2012-12-05 19:26:56 +0400
      > message:
      >   Bug #15954896 "SP, MULTI-TABLE DELETE AND LONG ALIAS".
      
        Using too long table aliases in stored routines might
        have caused server crashes.
      
        Code in sp_head::merge_table_list() which is responsible
        for collecting information about tables used in stored
        routine was not aware of the fact that table alias might
        have arbitrary length. I.e. it assumed that table alias
        can't be longer than NAME_LEN bytes and allocated buffer
        for a key identifying table accordingly.
      
        This patch fixes the issue by ensuring that we use
        dynamically allocated buffer for table key when table
        alias is too long. By default stack based buffer is used
        in which NAME_LEN bytes are reserved for table alias.
      d07b5f1c
  22. 05 Dec, 2012 2 commits
    • Vladislav Vaintroub's avatar
      MDEV-3918: myisamchk bogus error for files larger than 4GB. · c4b35f92
      Vladislav Vaintroub authored
      The failure is caused by failing stat() call . C Runtime function stat() uses old struct with 32bit st_size member,
      and since Visual Studio 2010 , it returns an error on st_size overflow (i.e on files larger than 4GB)
      
      Fix replaces stat() by my_stat(), the later is backed by 64bit-able stat64().
      c4b35f92
    • unknown's avatar
      MDEV-3914 fix. · 0aad592f
      unknown authored
      Fixed algorithm of detecting of first real table in view/subquery-in-the-FROM-clase.
      0aad592f