1. 24 Feb, 2006 1 commit
  2. 23 Feb, 2006 9 commits
  3. 22 Feb, 2006 4 commits
  4. 21 Feb, 2006 15 commits
  5. 20 Feb, 2006 7 commits
  6. 18 Feb, 2006 4 commits
    • guilhem@mysql.com's avatar
    • guilhem@mysql.com's avatar
      Fix for BUG#13897 "failure to do SET SQL_MODE=N where N is a number > 31" (the... · 37c1744a
      guilhem@mysql.com authored
      Fix for BUG#13897 "failure to do SET SQL_MODE=N where N is a number > 31" (the original bug's title isn't the simplest
      symptom). sys_var::check_set() was wrong. mysqlbinlog makes use of such SET SQL_MODE=N
      (where N is interpreted like if SQL_MODE was a field of type SET), so
      this bug affected recovery from binlogs if the server was running with certain SQL_MODE values,
      for example the default values on Windows (STRICT_TRANS_TABLES); to work around this bug people
      had to edit mysqlbinlog's output.
      37c1744a
    • guilhem@mysql.com's avatar
      Fix for BUG#14769 "Function fails to replicate if fails half-way (slave stops)": · 56bed24c
      guilhem@mysql.com authored
      if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
      slave would stop and complain that error code between him and master mismatch. 
      To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
      call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
      And: minor wording change in the help text.
      This cset will cause conflicts in 5.1, I'll merge.
      56bed24c
    • guilhem@mysql.com's avatar
      Fix for BUG#16559 "Replication Problems with Non transactional tables inside... · 4c5d18b1
      guilhem@mysql.com authored
      Fix for BUG#16559 "Replication Problems with Non transactional tables inside an interrupted trans.":
      problem was: when a connection disconnects having an open transaction affecting MyISAM and InnoDB, the ROLLBACK event stored in the binary log
      contained a non-zero error code (1053 because of the disconnection), so when slave applied the transaction, slave complained that its ROLLBACK succeeded
      (error_code=0) while master's had 1053, so slave stopped. But internally generated binlog events such as this ROLLBACK
      should always have 0 as error code, as is true in 4.1 and was accidentally broken in 5.0,
      so that there is no false alarm.
      4c5d18b1