1. 12 Jan, 2010 3 commits
    • Luis Soares's avatar
      Fixes for three test failures: · ca15e277
      Luis Soares authored
       - sys_vars.all_vars:
         Added test case for slave_type_conversions variable
       - rpl_row_idempotency
         Removed ER_SLAVE_AMBIGOUS_EXEC_MODE (which was removed by WL 4738)
         from the test case. Using ER_WRONG_VALUE_FOR_VAR instead.
       - mysqld--help-win
         Added missing help for --slave-type-conversions from the
         result file.
           
      ca15e277
    • unknown's avatar
      Auto merge. · 802ba52b
      unknown authored
      802ba52b
    • unknown's avatar
      Manual merge from next-mr. · 16e15e69
      unknown authored
      16e15e69
  2. 08 Jan, 2010 1 commit
    • Luis Soares's avatar
      Fixes rpl_stm_loaddata_concurrent failure in PB2. · 7f414733
      Luis Soares authored
      The test case did not start with fresh binlogs, so in some
      cases, dependending on the order MTR runs the tests, it would
      try to show binlog contents from invalid positions (binary log
      would contain unexpected events from previous test).
      
      We fix this by deploying a RESET MASTER at the beginning of the
      test case.
      7f414733
  3. 07 Jan, 2010 3 commits
    • Alfranio Correia's avatar
    • Alfranio Correia's avatar
      merge mysql-5.1-rep+2-delivery1 --> mysql-5.1-rpl-merge · 5dcb0e44
      Alfranio Correia authored
      Conflicts:
      
      Text conflict in .bzr-mysql/default.conf
      Text conflict in mysql-test/extra/rpl_tests/rpl_loaddata.test
      Text conflict in mysql-test/r/mysqlbinlog2.result
      Text conflict in mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
      Text conflict in mysql-test/suite/binlog/r/binlog_unsafe.result
      Text conflict in mysql-test/suite/rpl/r/rpl_insert_id.result
      Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result
      Text conflict in mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result
      Text conflict in mysql-test/suite/rpl/r/rpl_udf.result
      Text conflict in mysql-test/suite/rpl/t/rpl_slow_query_log.test
      Text conflict in sql/field.h
      Text conflict in sql/log.cc
      Text conflict in sql/log_event.cc
      Text conflict in sql/log_event_old.cc
      Text conflict in sql/mysql_priv.h
      Text conflict in sql/share/errmsg.txt
      Text conflict in sql/sp.cc
      Text conflict in sql/sql_acl.cc
      Text conflict in sql/sql_base.cc
      Text conflict in sql/sql_class.h
      Text conflict in sql/sql_db.cc
      Text conflict in sql/sql_delete.cc
      Text conflict in sql/sql_insert.cc
      Text conflict in sql/sql_lex.cc
      Text conflict in sql/sql_lex.h
      Text conflict in sql/sql_load.cc
      Text conflict in sql/sql_table.cc
      Text conflict in sql/sql_update.cc
      Text conflict in sql/sql_view.cc
      Conflict adding files to storage/innobase.  Created directory.
      Conflict because storage/innobase is not versioned, but has versioned children.  Versioned directory.
      Conflict adding file storage/innobase.  Moved existing file to storage/innobase.moved.
      Conflict adding files to storage/innobase/handler.  Created directory.
      Conflict because storage/innobase/handler is not versioned, but has versioned children.  Versioned directory.
      Contents conflict in storage/innobase/handler/ha_innodb.cc
      5dcb0e44
    • Luis Soares's avatar
      Fix for rpl_bug31076 valgrind failure which popped up after · a533cec7
      Luis Soares authored
      WL#5151 was pushed.
      
      Problem 1: Some old binlog events do not contain metadata. This
      makes checking whether the field can be converted or not rather
      impossible because one cannot compare, for instance, field sizes
      from original table and target table.
      
      Solution 1: When an event does not contain metadata, we will just
      check if field types are equal and assume that original field
      definition matched with the one in the target table.
      
      Problem 2: There is a second fix, which involves lack of
      information regarding maybe_null. This was causing a conditional
      jump warning when creating a conversion table. 
      
      Solution 2: We will just assume that all fields that need to be
      in the conversion table may be null.
      a533cec7
  4. 06 Jan, 2010 1 commit
  5. 05 Jan, 2010 2 commits
    • Alfranio Correia's avatar
      merge 5.1-rep+3 --> 5.1-rep+2-delivery1 · 9e2c9cd2
      Alfranio Correia authored
      9e2c9cd2
    • Alfranio Correia's avatar
      BUG#50038 Deadlock on flush logs with concurrent DML and RBR · 54b2371e
      Alfranio Correia authored
      In auto-commit mode, updating both trx and non-trx tables (i.e. issuing a mixed
      statement) causes the following sequence of events:
      
      1 - "Flush trx changes" (MYSQL_BIN_LOG::write) - T1:
        1.1 - mutex_lock (&LOCK_log)
        1.2 - mutex_lock (&LOCK_prep_xids)
        1.3 - increase prepared_xids
        1.4 - mutex_unlock (&LOCK_prep_xids)
        1.5 - mutex_unlock (&LOCK_log)
      
      2 - "Flush non-trx changes" (MYSQL_BIN_LOG::write) - T1:
        2.1 - mutex_lock (&LOCK_log)
        2.2 - mutex_unlock (&LOCK_log)
      
      3. "unlog" - T1
        3.1 - mutex_lock (&LOCK_prep_xids)
        3.2 - decrease prepared xids
        3.3 - pthread_cond_signal(&COND_prep_xids);
        3.4 - mutex_unlock (&LOCK_prep_xids)
      
      The "FLUSH logs" command produces the following sequence of events:
      
      1 - "FLUSH logs" command (MYSQL_BIN_LOG::new_file_impl) - user thread:
        1.1 - mutex_lock (&LOCK_log)
        1.2 - mutex_lock (&LOCK_prep_xids)
        1.3 - while (prepared_xids)  pthread_cond_wait(..., &LOCK_prep_xids);
        1.4 - mutex_unlock (&LOCK_prep_xids)
        1.5 - mutex_unlock (&LOCK_log)
      
      A deadlock will arise if T1 flushes the trx changes and thus increases
      prepared_xids but before it is able to continue the execution and flush the
      non-trx changes, an user thread calls the "FLUSH logs" command and wait that
      the prepared_xids is decreased and gets to zero. However, T1 cannot proceed
      with the call to "Flush non-trx changes" because it will block in the mutex
      "LOCK_log" and by consequence cannot complete the execution and call the
      unlog to decrease the prepared_xids.
      
      To fix the problem, we ensure that the non-trx changes are always flushed
      before the trx changes.
      
      Note that if you call "Flush non-trx changes" and a concurrent "FLUSH logs" is
      issued, the "Flush non-trx changes" may block, but a deadlock will never happen
      because the prepared_xids will eventually get to zero. Bottom line, there will
      not be any transaction able to increase the prepared_xids because they will
      block in the mutex "LOCK_log" (MYSQL_BIN_LOG::write) and those that increased
      the prepared_xids will eventually commit and decrease the prepared_xids.
      54b2371e
  6. 04 Jan, 2010 1 commit
  7. 31 Dec, 2009 1 commit
  8. 28 Dec, 2009 2 commits
  9. 27 Dec, 2009 1 commit
  10. 26 Dec, 2009 2 commits
  11. 25 Dec, 2009 2 commits
  12. 24 Dec, 2009 9 commits
  13. 23 Dec, 2009 12 commits