1. 09 Apr, 2009 14 commits
  2. 08 Apr, 2009 7 commits
  3. 07 Apr, 2009 5 commits
  4. 06 Apr, 2009 2 commits
  5. 05 Apr, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#39393 slave-skip-errors does not work when using ROW based replication · f9338b31
      Alfranio Correia authored
                                    
      RBR was not considering the option --slave-skip-errors.
                                    
      To fix the problem, we are reporting the ignored ERROR(s) as warnings thus avoiding 
      stopping the SQL Thread. Besides, it fixes the output of "SHOW VARIABLES LIKE 
      'slave_skip_errors'" which was showing nothing when the value "all" was assigned 
      to --slave-skip-errors.
                        
      @sql/log_event.cc
        skipped rbr errors when the option skip-slave-errors is set.
      @sql/slave.cc
        fixed the output of for SHOW VARIABLES LIKE 'slave_skip_errors'"
      @test-cases
        fixed the output of rpl.rpl_idempotency
        updated the test case rpl_skip_error
      f9338b31
  6. 03 Apr, 2009 6 commits
    • Serge Kozlov's avatar
      Bug#37716. · a81e21f8
      Serge Kozlov authored
      1. Test case was rewritten completely.
      2. Test covers 3 cases:
       a) do deadlock on slave, wait retries of transaction, unlock slave before lock
      timeout;
       b) do deadlock on slave and wait error 'lock timeout exceed' on slave;
       c) same as b) but if of max relay log size = 0;
      3. Added comments inline.
      4. Updated result file.
      a81e21f8
    • Davi Arnaut's avatar
      Merge Bug#43230 into mysql-5.1-bugteam · 54bf80b6
      Davi Arnaut authored
      54bf80b6
    • Davi Arnaut's avatar
      Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely · 72e97882
      Davi Arnaut authored
      The problem is that a SELECT .. FOR UPDATE statement might open
      a table and later wait for a impeding global read lock without
      noticing whether it is holding a table that is being waited upon
      the the flush phase of the process that took the global read
      lock.
      
      The same problem also affected the following statements:
      
      LOCK TABLES .. WRITE
      UPDATE .. SET (update and multi-table update)
      TRUNCATE TABLE ..
      LOAD DATA ..
      
      The solution is to make the above statements wait for a impending
      global read lock before opening the tables. If there is no
      impending global read lock, the statement raises a temporary
      protection against global read locks and progresses smoothly
      towards completion.
      
      Important notice: the patch does not try to address all possible
      cases, only those which are common and can be fixed unintrusively
      enough for 5.0.
      
      mysql-test/r/lock_multi.result:
        Add test case result for Bug#43230
      mysql-test/t/lock_multi.test:
        Add test case for Bug#43230
      sql/sql_lex.cc:
        Initialize flag.
      sql/sql_lex.h:
        Add a flag to the lexer.
      sql/sql_parse.cc:
        Wait for the global read lock is a write lock is going to be
        taken. The wait is done before opening tables.
      sql/sql_yacc.yy:
        Protect against the GRL if its a SELECT .. FOR UPDATE or LOCK TABLES
        .. WRITE statement.
      72e97882
    • Guangbao Ni's avatar
      AutoMerged from pushbuild mysql-5.1-bugteam · 102de8f5
      Guangbao Ni authored
      102de8f5
    • Guangbao Ni's avatar
      BUG#42640 mysqld crashes when unsafe statements are executed (STRICT_TRANS_TABLESmode) · 173d2953
      Guangbao Ni authored
      Mysql server crashes because unsafe statements warning is wrongly elevated to error,
      which is set the error status of Diagnostics_area of the thread in THD::binlog_query().
      Yet the caller believes that binary logging shouldn't touch the status, so it will
      set the status also later by my_ok(), my_error() or my_message() seperately
      according to the execution result of the statement or transaction.
      But the status of Diagnostics_area of the thread is allowed to set only once.
      
      Fixed to clear the error wrongly set by binary logging, but keep the warning message.
      
      mysql-test/suite/binlog/r/binlog_stm_ps.result:
        Change unsafe warning to NOTE level
      mysql-test/suite/binlog/r/binlog_unsafe.result:
        Test case result for unsafe statements to ensure mysql sever don't crash
      mysql-test/suite/binlog/t/binlog_unsafe.test:
        Test case for unsafe statements to ensure mysql sever don't crash
      mysql-test/suite/rpl/r/rpl_skip_error.result:
        Change unsafe warning to NOTE level
      mysql-test/suite/rpl/r/rpl_stm_loadfile.result:
        Change unsafe warning to NOTE level
      mysql-test/suite/rpl/r/rpl_udf.result:
        Change unsafe warning to NOTE level
      sql/sql_class.cc:
        the error status of the thread is cleared When a warning is elevated to an error
        because of unsafe warning of binary log.
      173d2953
    • Horst Hunger's avatar
      Fix belonging to bug#42838: Though this bug is only for 6.0 I put in some... · 92ea1722
      Horst Hunger authored
      Fix belonging to bug#42838: Though this bug is only for 6.0 I put in some updated result files for 6.0 and this are the corrsponding resul files for 5.1, so that sys_vars should then run successfully also in 5.1.
      92ea1722
  7. 02 Apr, 2009 5 commits