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 · e32cb3b3
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mar07/stage2/41
      
      e32cb3b3
    • unknown's avatar
      Merge quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/50 · 511ac0bd
      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
      511ac0bd
    • unknown's avatar
      Merge quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/40 · 1e11aff4
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/40
      
      1e11aff4
    • unknown's avatar
      6a69365f
    • unknown's avatar
      Merge mysql.com:/home/kent/bk/tmp/mysql-4.1-build · e08b3256
      unknown authored
      into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build
      
      e08b3256
    • unknown's avatar
      Merge kboortz@bk-internal.mysql.com:/home/bk/mysql-5.0 · 619e1a05
      unknown authored
      into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build
      
      619e1a05
    • unknown's avatar
      Merge kboortz@bk-internal.mysql.com:/home/bk/mysql-4.1 · c888d30e
      unknown authored
      into  mysql.com:/home/kent/bk/tmp/mysql-4.1-build
      
      c888d30e
    • unknown's avatar
      Bug#25222 Win32 HANDLE leak in my_sopen() · 242e5529
      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.
      242e5529
    • unknown's avatar
      A fix for the windows build (harmless warning). · 840c635c
      unknown authored
      
      sql/sql_lex.cc:
        A fix for the windows build.
      840c635c
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 17359389
      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.
      17359389
    • unknown's avatar
      A fix for Bug#26750 "valgrind leak in sp_head" (and post-review · b4558c5d
      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.
      b4558c5d
    • unknown's avatar
      Merge quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/41 · 738bb7fb
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/50
      
      738bb7fb
    • unknown's avatar
      Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-4.1-runtime · db44ba8f
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/41
      
      db44ba8f
    • unknown's avatar
      Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 9fda9562
      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
      9fda9562
    • unknown's avatar
      Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-4.1 · b86b259d
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/41
      
      b86b259d
    • unknown's avatar
      cd847bca
    • unknown's avatar
      Merge poseidon.mysql.com:/home/tomas/mysql-5.0-telco-gca · 53f814fa
      unknown authored
      into  poseidon.mysql.com:/home/tomas/mysql-5.0-ndb
      
      
      ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
        Auto merged
      53f814fa
    • unknown's avatar
      ndb - · 9b5ed15c
      unknown authored
        fix printout
        crashes testSystemRestart -n SR_UNDO
      
      
      ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
        fix printout
        crashes testSystemRestart -n SR_UNDO
      9b5ed15c
  4. 06 Mar, 2007 4 commits