An error occurred fetching the project authors.
  1. 27 Nov, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#48506 crash in CREATE TABLE IF NOT EXISTS <existing_view> LIKE · 6b31aa10
      Alfranio Correia authored
      <tmp_tbl> with RBL
      
      When binlogging the statement, the server always handle the existing
      object as a table, even though it is a view. However a view is
      handled differently in other parts of the code thus leading the
      statement to crash in RBL if the view exists.
      
      This happens because the underlying tables for the view are not opened
      when we try to call store_create_info() on the view in order to build
      a CREATE TABLE statement.
      
      This patch will only address the crash problem, other binlogging
      problems related to CREATE TABLE IF NOT EXISTS LIKE when the existing
      object is a view will be solved by BUG 47442.
      6b31aa10
  2. 03 Nov, 2009 1 commit
    • Alfranio Correia's avatar
      WL#2687 WL#5072 BUG#40278 BUG#47175 · 60d46624
      Alfranio Correia authored
      Non-transactional updates that take place inside a transaction present problems
      for logging because they are visible to other clients before the transaction
      is committed, and they are not rolled back even if the transaction is rolled
      back. It is not always possible to log correctly in statement format when both
      transactional and non-transactional tables are used in the same transaction.
      
      In the current patch, we ensure that such scenario is completely safe under the
      ROW and MIXED modes.
      60d46624
  3. 06 Oct, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#47678 Changes to n-tables that happen early in a trans. are only flushed upon commit · b31e0c9a
      Alfranio Correia authored
        Let
          - T be a transactional table and N non-transactional table.
          - B be begin, C commit and R rollback.
          - N be a statement that accesses and changes only N-tables.
          - T be a statement that accesses and changes only T-tables.
      
      In RBR, changes to N-tables that happen early in a transaction are not immediately flushed
      upon committing a statement. This behavior may, however, break consistency in the presence
      of concurrency since changes done to N-tables become immediately visible to other
      connections. To fix this problem, we do the following:
      
        . B N N T C would log - B N C B N C B T C.
        . B N N T R would log - B N C B N C B T R.
      
      Note that we are not preserving history from the master as we are introducing a commit that
      never happened. However, this seems to be more acceptable than the possibility of breaking
      consistency in the presence of concurrency.
      b31e0c9a
  4. 29 Sep, 2009 1 commit
  5. 03 Dec, 2008 1 commit
    • Mats Kindahl's avatar
      Bug #40116: Uncommited changes are replicated and stay on slave · 82757fdf
      Mats Kindahl authored
      after rollback on master
      
      When starting a transaction with a statement containing changes
      to both transactional tables and non-transactional tables, the
      statement is considered as non-transactional and is therefore
      written directly to the binary log. This behaviour was present
      in 5.0, and has propagated to 5.1.
      
      If a trigger containing a change of a non-transactional table is
      added to a transactional table, any changes to the transactional
      table is "tainted" as non-transactional.
      
      This patch solves the problem by removing the existing "hack" that
      allows non-transactional statements appearing first in a transaction
      to be written directly to the binary log. Instead, anything inside
      a transaction is treaded as part of the transaction and not written
      to the binary log until the transaction is committed.
      82757fdf
  6. 27 Nov, 2008 1 commit
  7. 08 Oct, 2008 1 commit
    • Mats Kindahl's avatar
      Bug #34707: Row based replication: slave creates table within wrong database · 70b18065
      Mats Kindahl authored
      The failure was caused by executing a CREATE-SELECT statement that creates a
      table in another database than the current one. In row-based logging, the
      CREATE statement was written to the binary log without the database, hence
      creating the table in the wrong database, causing the following inserts to
      fail since the table didn't exist in the given database.
      
      Fixed the bug by adding a parameter to store_create_info() that will make
      the function print the database name before the table name and used that
      in the calls that write the CREATE statement to the binary log. The database
      name is only printed if it is different than the currently selected database.
      
      The output of SHOW CREATE TABLE has not changed and is still printed without
      the database name.
      70b18065
  8. 19 Aug, 2008 1 commit
    • Mats Kindahl's avatar
      Bug #34707: Row based replication: slave creates table within wrong database · f0bf4a47
      Mats Kindahl authored
      The failure was caused by executing a CREATE-SELECT statement that creates a
      table in another database than the current one. In row-based logging, the
      CREATE statement was written to the binary log without the database, hence
      creating the table in the wrong database, causing the following inserts to
      fail since the table didn't exist in the given database.
      
      Fixed the bug by adding a parameter to store_create_info() that will make
      the function print the database name before the table name and used that
      in the calls that write the CREATE statement to the binary log. The database
      name is only printed if it is different than the currently selected database.
      
      The output of SHOW CREATE TABLE has not changed and is still printed without
      the database name.
      f0bf4a47
  9. 08 Apr, 2008 1 commit
    • aelkin/andrei@mysql1000.(none)'s avatar
      Bug #35762 Failing CREATE-SELECT steels Table map of the following query · 725d07d5
      aelkin/andrei@mysql1000.(none) authored
      Among two claimed artifacts the critical one is in that the Table map of 
      a query following the failing with a duplicate key error CREATE-SELECT is skipped from
      instantionating (and thus binlogging). That leads to sending a "chopped" group of the data
      row-events without the table map head to the slave. 
      The slave can not apply the only data row events.
      It's not easy to force the slave to react with an error in such a case (the second complaint
      on the bug report), because the lack of a table Rows_log_event::do_apply_event the data row event
      handler is a common situation which  normally designates the event has to be filtered out
      basing on the repliation do/ingore rules decision.
      
      Fixed: table map creating and binlogging is restored via deploying the standard cleanup call in
      select_create::abort().
      No error is reported if by chance the table map was not been binlogged.
      Leaving this out to resolve with considering how to combine the do/ingore rules with the situation
      when erronoulsy the Table_map is not written to binlog.
      725d07d5
  10. 28 Mar, 2008 1 commit
    • mats@mats-laptop.(none)'s avatar
      BUG#29020 (Event results not correctly replicated to slave in RBR): · c8c4500a
      mats@mats-laptop.(none) authored
      The bug allow multiple executing transactions working with non-transactional
      to interfere with each others by interleaving the events of different trans-
      actions.
      
      Bug is fixed by writing non-transactional events to the transaction cache and
      flushing the cache to the binary log at statement commit. To mimic the behavior
      of normal statement-based replication, we flush the transaction cache in row-
      based mode when there is no committed statements in the transaction cache,
      which means we are committing the first one. This means that it will be written
      to the binary log as a "mini-transaction" with just the rows for the statement.
      
      Note that the changes here does not take effect when building the server with
      HAVE_TRANSACTIONS set to false, but it is not clear if this was possible before
      this patch either.
      
      For row-based logging, we also have that when AUTOCOMMIT=1, the code now always
      generates a BEGIN/COMMIT pair for single statements, or BEGIN/ROLLBACK pair in the
      case of non-transactional changes in a statement that was rolled back. Note that
      for the case where changes to a non-transactional table causes a rollback due
      to error, the statement will now be logged with a BEGIN/ROLLBACK pair, even
      though some changes has been committed to the non-transactional table.
      c8c4500a
  11. 14 Mar, 2008 2 commits
  12. 14 Dec, 2007 1 commit
  13. 02 Aug, 2007 1 commit
  14. 31 Jul, 2007 1 commit
  15. 29 Jul, 2007 1 commit
    • cbell/Chuck@mysql_cab_desk.'s avatar
      WL#3228 (NDB) : RBR using different table defs on slave/master · 537c23e8
      cbell/Chuck@mysql_cab_desk. authored
      This patch adds the ability to store extra field metadata in the table
      map event. This data can include pack_length() or field_lenght() for
      fields such as CHAR or VARCHAR enabling developers to add code that
      can check for compatibilty between master and slave columns. More 
      importantly, the extra field metadata can be used to store data from the
      master correctly should a VARCHAR field on the master be <= 255 bytes 
      while the same field on the slave is > 255 bytes. 
      
      The patch also includes the needed changes to unpack to ensure that data
      which is smaller on the master can be unpacked correctly on the slave.
      
      WL#3915 : (NDB) master's cols > slave
      
      Slave starts accepting and handling rows of master's tables which have more columns.
      The most important part of implementation is how to caclulate the amount of bytes to
      skip for unknown by slave column.
      537c23e8
  16. 29 Jun, 2007 1 commit
  17. 27 Jun, 2007 1 commit
  18. 30 Mar, 2007 1 commit
  19. 29 Mar, 2007 1 commit
    • mats@romeo.(none)'s avatar
      WL#3464: Add replication event to denote gap in replication · 7c187c2c
      mats@romeo.(none) authored
      Adding an event that can be used to denote that an incident occured
      on the master. The event can be used to denote a gap in the replication
      stream, but can also be used to denote other incidents.
      
      In addition, the injector interface is extended with functions to
      generate an incident event. The function will also rotate the binary
      log after generating an incident event to get a fresh binary log.
      7c187c2c
  20. 07 Mar, 2007 1 commit
  21. 12 Feb, 2007 1 commit
  22. 21 Dec, 2006 1 commit
    • mats@romeo.(none)'s avatar
      BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' · be9ffb12
      mats@romeo.(none) authored
      from log):
      When row-based logging is used, the CREATE-SELECT is written as two
      parts: as a CREATE TABLE statement and as the rows for the table. For
      both transactional and non-transactional tables, the CREATE TABLE
      statement was written to the transaction cache, as were the rows, and
      on statement end, the entire transaction cache was written to the binary
      log if the table was non-transactional. For transactional tables, the
      events were kept in the transaction cache until end of transaction (or
      statement that were not part of a transaction).
      
      For the case when AUTOCOMMIT=0 and we are creating a transactional table
      using a create select, we would then keep the CREATE TABLE statement and
      the rows for the CREATE-SELECT, while executing the following statements.
      On a rollback, the transaction cache would then be cleared, which would
      also remove the CREATE TABLE statement. Hence no table would be created
      on the slave, while there is an empty table on the master.
      
      This relates to BUG#22865 where the table being created exists on the
      master, but not on the slave during insertion of rows into the newly
      created table. This occurs since the CREATE TABLE statement were still
      in the transaction cache until the statement finished executing, and
      possibly longer if the table was transactional.
      
      This patch changes the behaviour of the CREATE-SELECT statement by
      adding an implicit commit at the end of the statement when creating
      non-temporary tables. Hence, non-temporary tables will be written to the
      binary log on completion, and in the even of AUTOCOMMIT=0, a new
      transaction will be started. Temporary tables do not commit an ongoing
      transaction: neither as a pre- not a post-commit.
      
      The events for both transactional and non-transactional tables are
      saved in the transaction cache, and written to the binary log at end
      of the statement.
      be9ffb12
  23. 04 Jul, 2006 1 commit
  24. 20 Jun, 2006 1 commit
    • guilhem@mysql.com's avatar
      Fix for BUG#20522 "RBR: CREATE TEMPORARY TABLE SELECT writes to binlog · ff179e37
      guilhem@mysql.com authored
      though unneeded". It's indeed unneeded, as slave is only interested in
      permanent tables, and permanent tables don't depend on temporary tables
      when in row-based binlogging mode. And other CREATE TEMPORARY TABLE
      (referring no table or with LIKE) already don't write the CREATE to
      binlog in row-based mode. 
      ff179e37
  25. 31 May, 2006 1 commit
  26. 06 Mar, 2006 1 commit
  27. 24 Feb, 2006 1 commit
  28. 16 Feb, 2006 1 commit
  29. 13 Feb, 2006 1 commit
  30. 22 Dec, 2005 1 commit