1. 31 Jul, 2007 12 commits
  2. 30 Jul, 2007 5 commits
    • gshchepa/uchum@gleb.loc's avatar
      bigint.test: · 9200be40
      gshchepa/uchum@gleb.loc authored
        Fixing a typo in the test case.
      9200be40
    • gkodinov/kgeorge@magare.gmz's avatar
      (pushing for Andrei) · 9a0e6ec6
      gkodinov/kgeorge@magare.gmz authored
      Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack
        
      Once had been set the flag might later got reset inside of a stored routine 
      execution stack.
      The reason was in that there was no check if a new statement started at time 
      of resetting.
      The artifact affects most of binlogable DML queries. Notice, that multi-update 
      is wrapped up within
        bug@27716 fix, multi-delete bug@29136.
        
      Fixed with saving parent's statement flag of whether the statement modified 
      non-transactional table, and unioning (merging) the value with that was gained 
      in mysql_execute_command.
        
      Resettling thd->no_trans_update members into thd->transaction.`member`;
      Asserting code;
      Effectively the following properties are held.
        
      1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table
         reflects the fact if such a table got modified by the substatement.
         That also respects THD::really_abort_on_warnin() requirements.
      2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as
         the union of the values of all invoked sub-statements.
         That fixes this bug#27417;
      
      Computing of thd->transaction.all.modified_non_trans_table is refined to base to 
      the stmt's value for all the case including insert .. select statement which 
      before the patch had an extra issue bug@28960.
      Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in
      to temp_table select. 
        
      The supplied test verifies limitely, mostly asserts. The ultimate testing is defered
      for bug@13270, bug@23333.
      9a0e6ec6
    • evgen@moonbone.local's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 002696b6
      evgen@moonbone.local authored
      into  moonbone.local:/mnt/gentoo64/work/24989-bug-5.0-opt-mysql
      002696b6
    • evgen@moonbone.local's avatar
      Bug#24989: The DEADLOCK error is improperly handled by InnoDB. · 8de5603d
      evgen@moonbone.local authored
      When innodb detects a deadlock it calls ha_rollback_trans() to rollback the 
      main transaction. But such action isn't allowed from inside of triggers and
      functions. When it happen the 'Explicit or implicit commit' error is thrown
      even if there is no commit/rollback statements in the trigger/function. This
      leads to the user confusion.
      
      Now the convert_error_code_to_mysql() function doesn't call the 
      ha_rollback_trans() function directly but rather calls the
      mark_transaction_to_rollback function and returns an error.
      The sp_rcontext::find_handler() now doesn't allow errors to be caught by the
      trigger/function error handlers when the thd->is_fatal_sub_stmt_error flag
      is set. Procedures are still allowed to catch such errors.
      The sp_rcontext::find_handler function now accepts a THD handle as a parameter.
      The transaction_rollback_request and the is_fatal_sub_stmt_error flags are 
      added to the THD class. The are initialized by the THD class constructor.
      Now the ha_autocommit_or_rollback function rolls back main transaction
      when not in a sub statement and the thd->transaction_rollback_request
      is set.
      The THD::restore_sub_statement_state function now resets the 
      thd->is_fatal_sub_stmt_error flag on exit from a sub-statement.
      8de5603d
    • gkodinov/kgeorge@magare.gmz's avatar
      Moved the DBUG_ASSERT from bug 28983 to · b6bb988d
      gkodinov/kgeorge@magare.gmz authored
      a place where it would not obstruct
      correct multithreading.
      b6bb988d
  3. 29 Jul, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #30120. · 1eb20fc0
      gshchepa/uchum@gleb.loc authored
      SP with local variables with non-ASCII names crashed the server.
      
      The server replaces SP local variable names with NAME_CONST calls
      when putting statements into the binary log. It used UTF8-encoded
      item names as variable names for the replacement inside NAME_CONST
      calls. However, statement string may be encoded by any
      known character set by the SET NAMES statement.
      The server used byte length of UTF8-encoded names to increment
      the position in the query string that led to array index overrun.
      1eb20fc0
  4. 28 Jul, 2007 8 commits
  5. 27 Jul, 2007 4 commits
  6. 26 Jul, 2007 7 commits
  7. 25 Jul, 2007 3 commits
    • gshchepa/uchum@gleb.loc's avatar
      Merge gleb.loc:/home/uchum/work/bk/5.0 · bb22e366
      gshchepa/uchum@gleb.loc authored
      into  gleb.loc:/home/uchum/work/bk/5.0-opt
      bb22e366
    • acurtis/antony@xiphis.org/ltamd64.xiphis.org's avatar
      Bug#25679 · fbcd70a4
        "Federated Denial of Service"
        Federated storage engine used to attempt to open connections within
        the ::create() and ::open() methods which are invoked while LOCK_open
        mutex is being held by mysqld. As a result, no other client sessions
        can open tables while Federated is attempting to open a connection.
        Long DNS lookup times would stall mysqld's operation and a rogue
        connection string which connects to a remote server which simply
        stalls during handshake can stall mysqld for a much longer period of
        time.
        This patch moves the opening of the connection much later, when the
        federated actually issues queries, by which time the LOCK_open mutex is
        no longer being held.
      fbcd70a4
    • gshchepa/uchum@gleb.loc's avatar
      Merge gleb.loc:/home/uchum/work/bk/4.1-opt · 2c9eb163
      gshchepa/uchum@gleb.loc authored
      into  gleb.loc:/home/uchum/work/bk/5.0-opt
      2c9eb163