1. 27 Oct, 2010 1 commit
  2. 25 Oct, 2010 1 commit
  3. 23 Oct, 2010 1 commit
    • 's avatar
      Bug#27606 GRANT statement should be replicated with DEFINER information · 180e74bd
      authored
      "Grantor" columns' data is lost when replicating mysql.tables_priv.
      Slave SQL thread used its default user ''@'' as the grantor of GRANT|REVOKE
      statements executing on it.
      
      In this patch, current user is put in query log event for all GRANT and REVOKE
      statement, SQL thread uses the user in query log event as grantor.
      180e74bd
  4. 21 Oct, 2010 2 commits
    • Bjorn Munch's avatar
      Follow-up to Bug #55582 which allows checking strings in if · bad7fa7c
      Bjorn Munch authored
        Simplified cases where a select was used to compare variable against ''
      bad7fa7c
    • 's avatar
      Bug#55478 Row events wrongly apply on the temporary table of the same name · aa235b1b
      authored
      Rows events were applied wrongly on the temporary table with the same name.
      But rows events are generated only for base tables. As temporary
      table's data never be binlogged on row mode. Normally, base table of the
      same name cannot be updated if a temporary table has the same name.
      But there are two cases which can generate rows events on 
      the base table of same name.
            
      Case1: 'CREATE TABLE ... SELECT' statement.
      In mixed format, it will generate rows events if it is unsafe.
            
      Case2: Drop a transactional temporary table in a transaction
             (happens only on 5.5+).
      BEGIN;
      DROP TEMPORARY TABLE t1;       # t1 is a InnoDB table
      INSERT INTO t1 VALUES(rand()); # t1 is a MyISAM table
      COMMIT;
      'DROP TEMPORARY TABLE' will be put in the transaction cache and
      binlogged after the rows events generated by the 'INSERT' statement.
            
      After this patch, slave opens only base table when applying a rows event.
      aa235b1b
  5. 20 Oct, 2010 6 commits
  6. 19 Oct, 2010 11 commits
  7. 18 Oct, 2010 3 commits
  8. 16 Oct, 2010 1 commit
    • 's avatar
      Bug#56118 STOP SLAVE does not wait till trx with CREATE TMP TABLE ends, · 131e3e38
      authored
                replication aborts
      
      When recieving a 'SLAVE STOP' command, slave SQL thread will roll back the
      transaction and stop immidiately if there is only transactional table updated,
      even through 'CREATE|DROP TEMPOARY TABLE' statement are in it. But These
      statements can never be rolled back. Because the temporary tables to the user
      session mapping remain until 'RESET SLAVE', Therefore it will abort SQL thread
      with an error that the table already exists or doesn't exist, when it restarts
      and executes the whole transaction again.
      
      After this patch, SQL thread always waits till the transaction ends and then stops,
      if 'CREATE|DROP TEMPOARY TABLE' statement are in it.
      131e3e38
  9. 13 Oct, 2010 3 commits
  10. 11 Oct, 2010 1 commit
    • 's avatar
      Bug#56226 Table map set to 0 after altering MyISAM table · d7767d4a
      authored
      After ALTER TABLE which changed only table's metadata, row-based
      binlog sometimes got corrupted since the tablemap was unexpectedly
      set to 0 for subsequent updates to the same table.
      
      ALTER TABLE which changed only table's metadata always reset
      table_map_id for the table share to 0. Despite the fact that
      0 is a valid value for table_map_id, this step caused problems
      as it could have created situation in which we had more than
      one table share with table_map_id equal 0. If more than one
      table with table_map_id are 0 were updated in the same statement,
      updates to these different tables were written into the same
      rows event. This caused slave server to crash.
      
      This bug happens only on 5.1. It doesn't affect 5.5+.
      
      This patch solves this problem by ensuring that ALTER TABLE
      statements which change metadata only never reset table_map_id
      to 0. To do this it changes reopen_table() to correctly use
      refreshed table_map_id value instead of using the old one/
      resetting it.
      d7767d4a
  11. 10 Oct, 2010 1 commit
  12. 09 Oct, 2010 1 commit
    • 's avatar
      Bug#55375 Transaction bigger than max_binlog_cache_size crashes slave · b6682591
      authored
      When slave executes a transaction bigger than slave's max_binlog_cache_size,
      slave will crash. It is caused by the assert that server should only roll back
      the statement but not the whole transaction if the error ER_TRANS_CACHE_FULL 
      happens. But slave sql thread always rollbacks the whole transaction when
      an error happens.
                  
      Ather this patch, we always clear any error set in sql thread(it is different
      from the error in 'SHOW SLAVE STATUS') and it is cleared before rolling back
      the transaction.
      b6682591
  13. 07 Oct, 2010 1 commit
    • Martin Hansson's avatar
      Bug#56423: Different count with SELECT and CREATE SELECT queries · 9c82ecec
      Martin Hansson authored
      This is a regression from the fix for bug no 38999. A storage engine capable
      of reading only a subset of a table's columns updates corresponding bits in
      the read buffer to signal that it has read NULL values for the corresponding
      columns. It cannot, and should not, update any other bits. Bug no 38999
      occurred because the implementation of UPDATE statements compare the NULL bits
      using memcmp, inadvertently comparing bits that were never requested from the
      storage engine. The regression was caused by the storage engine trying to
      alleviate the situation by writing to all NULL bits, even those that it had no
      knowledge of. This has devastating effects for the index merge algorithm,
      which relies on all NULL bits, except those explicitly requested, being left
      unchanged.
      
      The fix reverts the fix for bug no 38999 in both InnoDB and InnoDB plugin and
      changes the server's method of comparing records. For engines that always read
      entire rows, we proceed as usual. For engines capable of reading only select
      columns, the record buffers are now compared on a column by column basis. An
      assertion was also added so that non comparable buffers are never read. Some
      relevant copy-pasted code was also consolidated in a new function.
      9c82ecec
  14. 06 Oct, 2010 2 commits
    • Luis Soares's avatar
      BUG#38718: slave sql thread crashes when reading relay log · 5109d540
      Luis Soares authored
            
      Suprisingly, a Slave_log_event would show up in the binary
      log. This event is never used and should not appear in the
      logs. As such, when the slave (or the mysqlbinlog tool) reads the
      event, it will hit an invalid pointer (reference to the
      descriptor event when deserializing the Slave_log_event was
      purposodely set to NULL).
            
      The presence of the Slave_log_event denotes a corrupted log, but
      we cannot tell how the log got corrupted in the first
      place. However, we can make the server cope with such events when
      it reads them - in case of log corruption - and fail gracefully.
           
      This patch makes the server/mysqlbinlog to report that it has
      found an invalid log event when Slave_log_event is read.
      5109d540
    • Alfranio Correia's avatar
      BUG#57098 RBR breaks on changing user password on 5.1 master -> 5.5 slave · 36183379
      Alfranio Correia authored
      Backported the patch for BUG#55452.
      36183379
  15. 05 Oct, 2010 5 commits