1. 09 Mar, 2007 9 commits
    • unknown's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 52fb60da
      unknown authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B26281-5.0-opt
      
      
      52fb60da
    • unknown's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · c7de22a1
      unknown authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B26281-5.0-opt
      
      
      sql/item_strfunc.cc:
        Auto merged
      mysql-test/r/func_str.result:
        resolved test merge conflicts
      mysql-test/t/func_str.test:
        resolved test merge conflicts
      c7de22a1
    • unknown's avatar
      Bug #26281: · 29b6d554
      unknown authored
       Fixed boundry checks in the INSERT() function:
       were one off.
      
      
      mysql-test/r/func_str.result:
        Bug #26281: test case
      mysql-test/t/func_str.test:
        Bug #26281: test case
      sql/item_strfunc.cc:
        Bug #26281: fixed boundry checks
      29b6d554
    • unknown's avatar
      Merge ibabaev@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · e68df7a1
      unknown authored
      into  olga.mysql.com:/home/igor/mysql-5.0-opt
      
      
      sql/item.cc:
        Auto merged
      e68df7a1
    • unknown's avatar
      Merge olga.mysql.com:/home/igor/mysql-5.0-opt · 413604f9
      unknown authored
      into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26661
      
      
      413604f9
    • unknown's avatar
      Fixed bug #26661: crash when order by clause in a union · 729bcaf4
      unknown authored
      construct references invalid name.
      Derived tables currently cannot use outer references.
      Thus there is no outer context for them.
      The 4.1 code takes this fact into account while the 
      Item_field::fix_outer_field code of 5.0 lost the check that blocks
      any attempts to resolve names in outer context for derived tables.
      
      
      mysql-test/r/union.result:
        Added a test case for bug #26661.
      mysql-test/t/union.test:
        Added a test case for bug #26661.
      sql/item.cc:
        Fixed bug #26661.
        Derived tables currently cannot use outer references.
        Thus there is no outer context for them.
        The 4.1 code takes this fact into account while the 
        Item_field::fix_outer_field code of 5.0 lost the check that blocks
        any attempts to resolve names in outer context for derived tables.
      729bcaf4
    • unknown's avatar
      Merge abotchkov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 76542acd
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      sql/sql_select.cc:
        Auto merged
      76542acd
    • unknown's avatar
      Merge mysql.com:/home/hf/work/mrg/mysql-4.1-opt · 3cd8b881
      unknown authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      
      
      3cd8b881
    • unknown's avatar
      aftermerge fix · 5c1e48c5
      unknown authored
      
      mysql-test/r/view.result:
        merging
      5c1e48c5
  2. 08 Mar, 2007 13 commits
  3. 07 Mar, 2007 18 commits
    • unknown's avatar
      Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-4.1-build · ae8cad44
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mar07/stage2/41
      
      
      ae8cad44
    • unknown's avatar
      Merge quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/50 · 30c1622e
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/50
      
      
      sql/mysqld.cc:
        Auto merged
      sql/sql_class.cc:
        Auto merged
      sql/sql_class.h:
        Auto merged
      sql/sql_parse.cc:
        Auto merged
      30c1622e
    • unknown's avatar
      Merge quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/40 · 7a512b02
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/40
      
      
      7a512b02
    • unknown's avatar
      5501a291
    • unknown's avatar
      Merge mysql.com:/home/kent/bk/tmp/mysql-4.1-build · 245f1308
      unknown authored
      into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build
      
      
      245f1308
    • unknown's avatar
      Merge kboortz@bk-internal.mysql.com:/home/bk/mysql-5.0 · dc451454
      unknown authored
      into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build
      
      
      dc451454
    • unknown's avatar
      Merge kboortz@bk-internal.mysql.com:/home/bk/mysql-4.1 · 4c1312d4
      unknown authored
      into  mysql.com:/home/kent/bk/tmp/mysql-4.1-build
      
      
      4c1312d4
    • unknown's avatar
      sql_select.cc: · 1631f65d
      unknown authored
        Postfix for bug#22331 for windows platform.
      explain.test, explain.result:
        Cleanup after bugfix#22331.
      
      
      mysql-test/t/explain.test:
        Cleanup after bugfix#22331.
      mysql-test/r/explain.result:
        Cleanup after bugfix#22331.
      sql/sql_select.cc:
        Postfix for bug#22331 for windows platform.
      1631f65d
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · d7738740
      unknown authored
      into  moonbone.local:/mnt/gentoo64/work/25373-bug-5.0-opt-mysql
      
      
      sql/sql_select.cc:
        Auto merged
      d7738740
    • unknown's avatar
      Merge moonbone.local:/mnt/gentoo64/work/22331-bug-5.0-opt-mysql · 6f18c392
      unknown authored
      into  moonbone.local:/mnt/gentoo64/work/25373-bug-5.0-opt-mysql
      
      
      mysql-test/r/subselect.result:
        Auto merged
      sql/sql_lex.h:
        Auto merged
      sql/sql_select.cc:
        Auto merged
      sql/sql_lex.cc:
        SCCS merged
      6f18c392
    • unknown's avatar
      Bug#25373: Stored functions wasn't compared correctly which leads to a wrong · 11b533b8
      unknown authored
      result.
      
      For built-in functions like sqrt() function names are hard-coded and can be
      compared by pointer. But this isn't the case for a used-defined stored
      functions - names there are dynamical and should be compared as strings.
      
      Now the Item_func::eq() function employs my_strcasecmp() function to compare
      used-defined stored functions names.
      
      
      mysql-test/t/sp.test:
        Added a test case for bug#25373: Stored functions wasn't compared correctly which leads to a wrong result.
      mysql-test/r/sp.result:
        Added a test case for bug#25373: Stored functions wasn't compared correctly which leads to a wrong result.
      sql/item_func.cc:
        Bug#25373: Stored functions wasn't compared correctly which leads to a wrong
        result.
        Now the Item_func::eq() function employs my_strcasecmp() function to compare
        used-defined stored functions names.
      11b533b8
    • unknown's avatar
      Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized · 6de27791
      unknown authored
      away.
      
      During optimization stage the WHERE conditions can be changed or even
      be removed at all if they know for sure to be true of false. Thus they aren't
      showed in the EXPLAIN EXTENDED which prints conditions after optimization.
      
      Now if all elements of an Item_cond were removed this Item_cond is substituted
      for an Item_int with the int value of the Item_cond.
      If there were conditions that were totally optimized away then values of the
      saved cond_value and having_value will be printed instead.
      
      
      mysql-test/t/explain.test:
        Added a test case for the bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away.
      mysql-test/r/subselect.result:
        Corrected test case result after fix for bug#22331.
      mysql-test/r/func_test.result:
        Corrected test case result after fix for bug#22331.
      mysql-test/r/explain.result:
        Added a test case for the bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away.
      sql/sql_select.cc:
        Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized
        away.
        Now if all elements of an Item_cond were removed this Item_cond is substituted
        for an Item_int with the int value of the Item_cond.
        If there were conditions that were totally optimized away then values of the
        saved cond_value and having_value will be printed instead.
      sql/sql_lex.h:
        Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized
        away.
        The cond_value and the having_value variables are
        added to the SELECT_LEX class.
      sql/sql_lex.cc:
        Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized
        away.
        The initialization of the cond_value and the having_value variables.
      sql/sql_select.h:
        Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized
        away.
        Now having_value is also stored in the JOIN class.
      6de27791
    • unknown's avatar
      Merge olga.mysql.com:/home/igor/mysql-5.0-opt · e4cdb580
      unknown authored
      into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26560
      
      
      sql/sql_base.cc:
        Auto merged
      sql/sql_select.cc:
        Auto merged
      e4cdb580
    • unknown's avatar
      Bug#25222 Win32 HANDLE leak in my_sopen() · 83def161
      unknown authored
      - When attempting to associate a Windows File handle to a C run-time file
      handle there is an upper bound.  Once reached, the newly created handles
      will cause a memory leak since they are not properly associated with a
      handle that can later be cleaned up.
      
      
      mysys/my_open.c:
        Bug#25222 Win32 HANDLE leak in my_sopen()
        - Check for failure in _open_osfhandle and close allocated HANDLE on failure.
      83def161
    • unknown's avatar
      A fix for the windows build (harmless warning). · 4d6e16f2
      unknown authored
      
      sql/sql_lex.cc:
        A fix for the windows build.
      4d6e16f2
    • unknown's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · cbd324d2
      unknown authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B19342-5.0-opt
      
      
      cbd324d2
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 7f69b747
      unknown authored
      into  bodhi.local:/opt/local/work/mysql-5.0-26750
      
      
      sql/mysqld.cc:
        Auto merged
      sql/sql_class.cc:
        Auto merged
      sql/sql_parse.cc:
        Auto merged
      sql/sql_class.h:
        Manual merge.
      7f69b747
    • unknown's avatar
      A fix for Bug#26750 "valgrind leak in sp_head" (and post-review · 053c6c01
      unknown authored
      fixes).
      
      The legend: on a replication slave, in case a trigger creation
      was filtered out because of application of replicate-do-table/
      replicate-ignore-table rule, the parsed definition of a trigger was not 
      cleaned up properly. LEX::sphead member was left around and leaked 
      memory. Until the actual implementation of support of 
      replicate-ignore-table rules for triggers by the patch for Bug 24478 it 
      was never the case that "case SQLCOM_CREATE_TRIGGER"
      was not executed once a trigger was parsed,
      so the deletion of lex->sphead there worked and the memory did not leak.
      
      The fix: 
      
      The real cause of the bug is that there is no 1 or 2 places where
      we can clean up the main LEX after parse. And the reason we 
      can not have just one or two places where we clean up the LEX is
      asymmetric behaviour of MYSQLparse in case of success or error. 
      
      One of the root causes of this behaviour is the code in Item::Item()
      constructor. There, a newly created item adds itself to THD::free_list
      - a single-linked list of Items used in a statement. Yuck. This code
      is unaware that we may have more than one statement active at a time,
      and always assumes that the free_list of the current statement is
      located in THD::free_list. One day we need to be able to explicitly
      allocate an item in a given Query_arena.
      Thus, when parsing a definition of a stored procedure, like
      CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
      we actually need to reset THD::mem_root, THD::free_list and THD::lex
      to parse the nested procedure statement (SELECT *).
      The actual reset and restore is implemented in semantic actions
      attached to sp_proc_stmt grammar rule.
      The problem is that in case of a parsing error inside a nested statement
      Bison generated parser would abort immediately, without executing the
      restore part of the semantic action. This would leave THD in an 
      in-the-middle-of-parsing state.
      This is why we couldn't have had a single place where we clean up the LEX
      after MYSQLparse - in case of an error we needed to do a clean up
      immediately, in case of success a clean up could have been delayed.
      This left the door open for a memory leak.
      
      One of the following possibilities were considered when working on a fix:
      - patch the replication logic to do the clean up. Rejected
      as breaks module borders, replication code should not need to know the
      gory details of clean up procedure after CREATE TRIGGER.
      - wrap MYSQLparse with a function that would do a clean up.
      Rejected as ideally we should fix the problem when it happens, not
      adjust for it outside of the problematic code.
      - make sure MYSQLparse cleans up after itself by invoking the clean up
      functionality in the appropriate places before return. Implemented in 
      this patch.
      - use %destructor rule for sp_proc_stmt to restore THD - cleaner
      than the prevoius approach, but rejected
      because needs a careful analysis of the side effects, and this patch is 
      for 5.0, and long term we need to use the next alternative anyway
      - make sure that sp_proc_stmt doesn't juggle with THD - this is a 
      large work that will affect many modules.
      
      Cleanup: move main_lex and main_mem_root from Statement to its
      only two descendants Prepared_statement and THD. This ensures that
      when a Statement instance was created for purposes of statement backup,
      we do not involve LEX constructor/destructor, which is fairly expensive.
      In order to track that the transformation produces equivalent 
      functionality please check the respective constructors and destructors
      of Statement, Prepared_statement and THD - these members were
      used only there.
      This cleanup is unrelated to the patch.
      
      
      sql/log_event.cc:
        THD::main_lex is private and should not be used.
      sql/mysqld.cc:
        Move MYSQLerror to sql_yacc.yy as it depends on LEX headers now.
      sql/sql_class.cc:
        Cleanup: move main_lex and main_mem_root to THD and Prepared_statement
      sql/sql_class.h:
        Cleanup: move main_lex and main_mem_root to THD and Prepared_statement
      sql/sql_lex.cc:
        Implement st_lex::restore_lex()
      sql/sql_lex.h:
        Declare st_lex::restore_lex().
      sql/sql_parse.cc:
        Consolidate the calls to unit.cleanup() and deletion of lex->sphead
        in mysql_parse (COM_QUERY handler)
      sql/sql_prepare.cc:
        No need to delete lex->sphead to restore memory roots now in case of a 
        parse error - this is done automatically inside MYSQLparse
      sql/sql_trigger.cc:
        This code could lead to double deletion apparently, as in case
        of an error lex.sphead was never reset.
      sql/sql_yacc.yy:
        Trap all returns from the parser to ensure that MySQL-specific cleanup
        is invoked: we need to restore the global state of THD and LEX in 
        case of a parsing error. In case of a parsing success this happens as 
        part of normal grammar reduction process.
      053c6c01