1. 09 Apr, 2009 6 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 · 1287d8c5
      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
      1287d8c5
  6. 03 Apr, 2009 6 commits
    • Serge Kozlov's avatar
      Bug#37716. · 2ee7a7cf
      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.
      2ee7a7cf
    • Davi Arnaut's avatar
      Merge Bug#43230 into mysql-5.1-bugteam · ec762cbd
      Davi Arnaut authored
      ec762cbd
    • Davi Arnaut's avatar
      Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely · aebaf079
      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.
      aebaf079
    • Guangbao Ni's avatar
      AutoMerged from pushbuild mysql-5.1-bugteam · 48f43531
      Guangbao Ni authored
      48f43531
    • Guangbao Ni's avatar
      BUG#42640 mysqld crashes when unsafe statements are executed (STRICT_TRANS_TABLESmode) · 61ce7092
      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.
      61ce7092
    • Horst Hunger's avatar
      Fix belonging to bug#42838: Though this bug is only for 6.0 I put in some... · 33364242
      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.
      33364242
  7. 02 Apr, 2009 10 commits
  8. 01 Apr, 2009 3 commits