1. 18 Feb, 2008 1 commit
  2. 15 Feb, 2008 7 commits
  3. 14 Feb, 2008 3 commits
  4. 13 Feb, 2008 2 commits
  5. 12 Feb, 2008 3 commits
  6. 11 Feb, 2008 3 commits
  7. 09 Feb, 2008 1 commit
  8. 08 Feb, 2008 2 commits
    • aelkin/andrei@mysql1000.dsl.inet.fi's avatar
      bug#34427 slave misses rendezvous in rpl_variables · f01531b7
      aelkin/andrei@mysql1000.dsl.inet.fi authored
      There was no instruction in the test that enforces the slave successfully connect
      to the master.
      The way the test was been written allowed the slave to had been late for rendezvous 
      so that about-connecting time queries to the master failed and are error-logged
      to had been seen in Warnings of pb.
      
      Fixed with adding a sychronization primitive to the test.
      No test case is possible, observe error logs on pb.
      
      Todo: revise need of rpl_report.pl's rules due to failing execution of
      queries from get_master_verion_and_clock().
      Any test should try to use a synchornization primitive like the current fix
      makes and do not let the slave to miss successful connecting.
      f01531b7
    • sven@riska.(none)'s avatar
      BUG#33247: mysqlbinlog does not clean up after itself on abnormal termination · d1963d06
      sven@riska.(none) authored
      Problem: mysqlbinlog does not free memory if an error happens.
      Fix: binlog-processing functions do not call exit() anymore. Instead, they
      print an error and return an error code. Error codes are propagated all
      the way back to main, and all allocated memory is freed on the way.
      d1963d06
  9. 07 Feb, 2008 6 commits
  10. 06 Feb, 2008 4 commits
  11. 05 Feb, 2008 6 commits
  12. 04 Feb, 2008 2 commits
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug#33329 extraneous ROLLBACK in binlog on connection · 7880fade
      aelkin/elkin@koti.dsl.inet.fi authored
                  does not use trans tables
      
      There had been two issues.
      Rollback statement was recorded in binlog even though a multi-update
      had not modified any non-transactional table.
      The reason for this artifact was a false initial value of multi_update::transactional_tables.
      Yet another artifact that explained on the bug page is that 
      `ha_autocommit_or_rollback' works differently depending on whether
      a transaction engine has been compiled in. 
      
      Fixed: with setting multi_update::transactional_tables to zero at initialization
      time. Multi-update on non-trans table won't cause ROLLBACK in binlog with
      either compilation option.
      
      The 2nd mentioned artifact comprises a self-standing issue (to be reported
      separately).
      7880fade
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug #32790 crash in trigger.test with InnoDB for a table · 991b4820
      aelkin/elkin@koti.dsl.inet.fi authored
      the reason for the failure were incorrect asserts.
      
      Removing asserts altogether as there is no the implication does not hold
      (as explained in the comments for the file).
      991b4820