1. 15 Feb, 2007 4 commits
    • guilhem@gbichot3.local's avatar
      Manual merge from 5.0-rpl, of fixes for: · 39de08fd
      guilhem@gbichot3.local authored
      1)
        BUG#25507 "multi-row insert delayed + auto increment causes
        duplicate key entries on slave" (two concurrrent connections doing
        multi-row INSERT DELAYED to insert into an auto_increment column,
        caused replication slave to stop with "duplicate key error" (and
        binlog was wrong), and BUG#26116 "If multi-row INSERT
        DELAYED has errors, statement-based binlogging breaks" (the binlog
        was not accounting for all rows inserted, or slave could stop).
        The fix is that: in statement-based binlogging, a multi-row INSERT
        DELAYED is silently converted to a non-delayed INSERT.
        This is supposed to not affect many 5.1 users as in 5.1, the default
        binlog format is "mixed", which does not have the bug (the bug is
        only with binlog_format=STATEMENT).
        We should document how the system delayed_insert thread decides of
        its binlog format (which is not modified by this patch):
        this decision is taken when the thread is created
        and holds until it is terminated (is not affected by any later change
        via SET GLOBAL BINLOG_FORMAT). It is also not affected by the binlog
        format of the connection which issues INSERT DELAYED (this binlog
        format does not affect how the row will be binlogged).
        If one wants to change the binlog format of its server with SET
        GLOBAL BINLOG_FORMAT, it should do FLUSH TABLES to be sure all
        delayed_insert threads terminate and thus new threads are created,
        taking into account the new format.
      2)
        BUG#24432
        "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values".
        When in an INSERT ON DUPLICATE KEY UPDATE, using
        an autoincrement column, we inserted some autogenerated values and
        also updated some rows, some autogenerated values were not used
        (for example, even if 10 was the largest autoinc value in the table
        at the start of the statement, 12 could be the first autogenerated
        value inserted by the statement, instead of 11). One autogenerated
        value was lost per updated row. Led to exhausting the range of the
        autoincrement column faster.
        Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12.
        This bug breaks replication from a pre-5.0.24/pre-5.1.12 master.
        But the present bugfix, as it makes INSERT ON DUP KEY UPDATE
        behave like pre-5.0.24/pre-5.1.12, breaks replication from a
        [5.0.24,5.0.34]/[5.1.12,5.1.15]
        master to a fixed (5.0.36/5.1.16) slave! To warn users against this when
        they upgrade their slave, as agreed with the support team, we add
        code for a fixed slave to detect that it is connected to a buggy
        master in a situation (INSERT ON DUP KEY UPDATE into autoinc column)
        likely to break replication, in which case it cannot replicate so
        stops and prints a message to the slave's error log and to SHOW SLAVE
        STATUS.
        For 5.0.36->[5.0.24,5.0.34] replication or 5.1.16->[5.1.12,5.1.15]
        replication we cannot warn as master
        does not know the slave's version (but we always recommended to users
        to have slave at least as new as master).
        As agreed with support, I have asked for an alert to be put into
        the MySQL Network Monitoring and Advisory Service.
      3) note that I'll re-enable rpl_insert_id as soon as 5.1-rpl gets
        the changes from the main 5.1.
      39de08fd
    • guilhem@gbichot3.local's avatar
      Merge gbichot3.local:/home/mysql_src/mysql-5.0-rpl-25507 · 03dfe4ab
      guilhem@gbichot3.local authored
      into  gbichot3.local:/home/mysql_src/mysql-5.1-rpl-25507
      03dfe4ab
    • guilhem@gbichot3.local's avatar
      Backport from the Falcon tree. · 2f75c9cd
      guilhem@gbichot3.local authored
      When opening/creating the transaction coordinator's log, if binlog is
      used, the tc log is the binlog so we use the binlog's name; otherwise
      we use the mmap-based log, named after the mandatory argument of the
      --log-tc option (meant for that).
      2f75c9cd
    • guilhem@gbichot3.local's avatar
      Fix for BUG#25507 "multi-row insert delayed + auto increment causes · 8b1609a6
      guilhem@gbichot3.local authored
      duplicate key entries on slave" (two concurrrent connections doing
      multi-row INSERT DELAYED to insert into an auto_increment column,
      caused replication slave to stop with "duplicate key error" (and
      binlog was wrong)), and BUG#26116 "If multi-row INSERT
      DELAYED has errors, statement-based binlogging breaks" (the binlog
      was not accounting for all rows inserted, or slave could stop).
      The fix is that: if (statement-based) binlogging is on, a multi-row
      INSERT DELAYED is silently converted to a non-delayed INSERT.
      Note: it is not possible to test BUG#25507 in 5.0 (requires mysqlslap),
      so it is tested only in the changeset for 5.1. However, BUG#26116
      is tested here, and the fix for BUG#25507 is the same code change.
      8b1609a6
  2. 08 Feb, 2007 2 commits
    • guilhem@gbichot3.local's avatar
      Merge gbichot@bk-internal.mysql.com:/home/bk/mysql-5.0-rpl · 1e74079b
      guilhem@gbichot3.local authored
      into  gbichot3.local:/home/mysql_src/mysql-5.0-rpl-24432
      1e74079b
    • guilhem@gbichot3.local's avatar
      Fix for BUG#24432 · b3a03dad
      guilhem@gbichot3.local authored
      "INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values".
      When in an INSERT ON DUPLICATE KEY UPDATE, using
      an autoincrement column, we inserted some autogenerated values and
      also updated some rows, some autogenerated values were not used
      (for example, even if 10 was the largest autoinc value in the table
      at the start of the statement, 12 could be the first autogenerated
      value inserted by the statement, instead of 11). One autogenerated
      value was lost per updated row. Led to exhausting the range of the
      autoincrement column faster.
      Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12.
      This bug breaks replication from a pre-5.0.24 master.
      But the present bugfix, as it makes INSERT ON DUP KEY UPDATE
      behave like pre-5.0.24, breaks replication from a [5.0.24,5.0.34]
      master to a fixed (5.0.36) slave! To warn users against this when
      they upgrade their slave, as agreed with the support team, we add
      code for a fixed slave to detect that it is connected to a buggy
      master in a situation (INSERT ON DUP KEY UPDATE into autoinc column)
      likely to break replication, in which case it cannot replicate so
      stops and prints a message to the slave's error log and to SHOW SLAVE
      STATUS.
      For 5.0.36->[5.0.24,5.0.34] replication we cannot warn as master
      does not know the slave's version (but we always recommended to users
      to have slave at least as new as master).
      As agreed with support, I'll also ask for an alert to be put into
      the MySQL Network Monitoring and Advisory Service.
      b3a03dad
  3. 01 Feb, 2007 1 commit
  4. 31 Jan, 2007 1 commit
  5. 24 Jan, 2007 1 commit
    • bar@mysql.com's avatar
      Bug#25815 Data truncated for column TEXT · ffeaffc2
      bar@mysql.com authored
      Problem: "Data truncated" warning was incorrectly generated
      when storing a Japanese character encoded in utf8
      into a cp932 column.
      Reason: Incorrect wrong warning condition
      compared the original length of the character in bytes
      (which is 3 in utf8) to the converted length of the
      character in bytes (which is 2 in cp932).
      Fix: use "how many bytes were scanned from input" instead
      of "how many bytes were put to the column" in the condition.
      ffeaffc2
  6. 23 Jan, 2007 2 commits
  7. 22 Jan, 2007 1 commit
  8. 18 Jan, 2007 5 commits
  9. 17 Jan, 2007 12 commits
  10. 16 Jan, 2007 9 commits
  11. 15 Jan, 2007 2 commits