1. 09 Mar, 2007 9 commits
  2. 08 Mar, 2007 9 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
      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 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
    • unknown's avatar
      Merge quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/41 · c4390d05
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/50
      
      
      c4390d05
    • unknown's avatar
      Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-4.1-runtime · cd5140d3
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/41
      
      
      cd5140d3
    • unknown's avatar
      Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · a966b0b7
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/50
      
      
      mysql-test/mysql-test-run.pl:
        Auto merged
      mysql-test/r/sp.result:
        Auto merged
      mysql-test/t/sp.test:
        Auto merged
      sql/item_cmpfunc.cc:
        Auto merged
      sql/item_cmpfunc.h:
        Auto merged
      sql/mysqld.cc:
        Auto merged
      sql/sql_class.cc:
        Auto merged
      sql/sql_class.h:
        Auto merged
      sql/sql_parse.cc:
        Auto merged
      a966b0b7
    • unknown's avatar
      Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-4.1 · b68519f7
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/41
      
      
      b68519f7
    • unknown's avatar
      a58b9b05
    • unknown's avatar
      Merge poseidon.mysql.com:/home/tomas/mysql-5.0-telco-gca · 8bf05c96
      unknown authored
      into  poseidon.mysql.com:/home/tomas/mysql-5.0-ndb
      
      
      ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
        Auto merged
      8bf05c96
    • unknown's avatar
      ndb - · cddc7687
      unknown authored
        fix printout
        crashes testSystemRestart -n SR_UNDO
      
      
      ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
        fix printout
        crashes testSystemRestart -n SR_UNDO
      cddc7687
  4. 06 Mar, 2007 4 commits