1. 11 Feb, 2013 1 commit
    • unknown's avatar
      MDEV-4123 fix. · 5a7bee5c
      unknown authored
      Missed update_used_tables() call for multi-update values.
      5a7bee5c
  2. 04 Feb, 2013 1 commit
    • unknown's avatar
      Fix for bug MDEV-765 (LP:825075) · 12bd3ddf
      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
      
      12bd3ddf
  3. 28 Jan, 2013 2 commits
  4. 26 Jan, 2013 1 commit
  5. 25 Jan, 2013 7 commits
  6. 24 Jan, 2013 2 commits
  7. 22 Jan, 2013 1 commit
  8. 21 Jan, 2013 4 commits
    • Igor Babaev's avatar
      Merge 5.1->5.2 · 2ffdb815
      Igor Babaev authored
      2ffdb815
    • Igor Babaev's avatar
      Merge. · 9458e282
      Igor Babaev authored
      9458e282
    • Igor Babaev's avatar
      Fixed bug mdev-4063 (bug #56927). · 3cecaef4
      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.
      3cecaef4
    • Sergei Golubchik's avatar
      MDEV-4029 SELECT on information_schema using a subquery locks up the... · a5b670b5
      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.
      a5b670b5
  9. 20 Jan, 2013 1 commit
  10. 16 Jan, 2013 2 commits
    • Igor Babaev's avatar
      Corrected the fix for bug mdev-3938. · 17746e7e
      Igor Babaev authored
      17746e7e
    • unknown's avatar
      MDEV-4056 fix. · 4cf8fe04
      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().
      4cf8fe04
  11. 17 Jan, 2013 2 commits
    • unknown's avatar
      MDEV-3900 Optimizer difference between MySQL and MariaDB with stored functions... · 8704113b
      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.
      
      8704113b
    • unknown's avatar
      backport of: · 9ba6bb1b
      unknown authored
      Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
      This fixed failing test in group_by.test
      9ba6bb1b
  12. 16 Jan, 2013 2 commits
    • unknown's avatar
      MDEV-3988 fix. · e744717c
      unknown authored
      Subquery turned into constant too late to be excluded from grouping list so test for constant added to the create_temp_table().
      e744717c
    • Igor Babaev's avatar
      Fixed bug mdev-3938. · 9157ee32
      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.
      9157ee32
  13. 12 Jan, 2013 1 commit
    • Igor Babaev's avatar
      Fixed bug mdev-4025. · 65931211
      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.
      65931211
  14. 11 Jan, 2013 1 commit
    • Vladislav Vaintroub's avatar
      MDEV-4020 : Make sure strmov symbol is exported by client library on Linux... · f8c8f96e
      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.
      f8c8f96e
  15. 10 Jan, 2013 2 commits
  16. 09 Jan, 2013 1 commit
  17. 08 Jan, 2013 1 commit
  18. 28 Dec, 2012 1 commit
    • unknown's avatar
      MDEV-3873 & MDEV-3876 & MDEV-3912 : Wrong result (extra rows) with ALL subquery · 91e4632e
      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.
      91e4632e
  19. 21 Dec, 2012 3 commits
  20. 19 Dec, 2012 1 commit
    • unknown's avatar
      MDEV-3928: Assertion `example' failed in Item_cache::is_expensive_processor... · dccec3ea
      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.
      dccec3ea
  21. 11 Dec, 2012 1 commit
  22. 07 Dec, 2012 1 commit
    • Joerg Bruehe's avatar
      Last-minute fix to 5.1.67, · a7f76a71
      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.
      a7f76a71
  23. 05 Dec, 2012 1 commit
    • Vladislav Vaintroub's avatar
      MDEV-3918: myisamchk bogus error for files larger than 4GB. · 008fd351
      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().
      008fd351