An error occurred fetching the project authors.
  1. 12 Dec, 2007 1 commit
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug#31552 Replication breaks when deleting rows from out-of-sync table · d8d6db6f
      aelkin/elkin@koti.dsl.inet.fi authored
          without PK
      Bug#31609 Not all RBR slave errors reported as errors
      bug#32468 delete rows event on a table with foreign key constraint fails
      
      The first two bugs comprise idempotency issues.
      First, there was no error code reported under conditions of the bug
      description although the slave sql thread halted.
      Second, executions were different with and without presence of prim key in
      the table.
      Third, there was no way to instruct the slave whether to ignore an error
      and skip to the following event or to halt.
      Fourth, there are handler errors which might happen due to idempotent
      applying of binlog but those were not listed among the "idempotent" error
      list.
      
      All the named issues are addressed.
      Wrt to the 3rd, there is the new global system variable, changeble at run
      time, which controls the slave sql thread behaviour.
      The new variable allows further extensions to mimic the sql_mode
      session/global variable.
      To address the 4th, the new bug#32468 had to be fixed as it was staying
      in the way.
      d8d6db6f
  2. 23 Nov, 2007 1 commit
  3. 13 Nov, 2007 2 commits
  4. 12 Nov, 2007 1 commit
  5. 09 Nov, 2007 1 commit
    • mats@capulet.net's avatar
      BUG#31793 (log event corruption causes crash): · a432d3de
      mats@capulet.net authored
      When running mysqlbinlog on a 64-bit machine with a corrupt relay log,
      it causes mysqlbinlog to crash. In this case, the crash is caused
      because a request for 18446744073709534806U bytes is issued, which
      apparantly can be served on a 64-bit machine (speculatively, I assume)
      but this causes the memcpy() issued later to copy the data to segfault.
      
      The request for the number of bytes is caused by a computation
      of data_len - server_vars_len where server_vars_len is corrupt in such
      a sense that it is > data_len. This causes a wrap-around, with the
      the data_len given above.
      
      This patch adds a check that if server_vars_len is greater than
      data_len before the substraction, and aborts reading the event in
      that case marking the event as invalid. It also adds checks to see
      that reading the server variables does not go outside the bounds
      of the available space, giving a limited amount of integrity check.
      a432d3de
  6. 07 Nov, 2007 2 commits
  7. 30 Oct, 2007 1 commit
    • mats@kindahl-laptop.dnsalias.net's avatar
      BUG#19958 (RBR idempotency issue for UPDATE and DELETE): · 9cc4b8dd
      mats@kindahl-laptop.dnsalias.net authored
      The rpl_trigger test case indicated a problem with idempotency support when run
      under row-based replication, which this patch fixes.
      
      However, despite this, the test is not designed for execution under row-based
      replication and hence rpl_trigger.test is not executed under row-based
      replication.
      
      The problem is that the test expects triggers to be executed when the slave
      updates rows on the slave, and this is (deliberately) not done with row-based
      replication.
      9cc4b8dd
  8. 29 Oct, 2007 1 commit
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug #27571 asynchronousity in setting mysql_`query`::error and · 27436f0b
      aelkin/elkin@koti.dsl.inet.fi authored
                 Query_log_event::error_code
      
      A query can perform completely having the local var error of mysql_$query
      zero, where $query in insert, update, delete, load,
      and be  binlogged with error_code e.g KILLED_QUERY while there is no
      reason do to so.
      That can happen because Query_log_event consults thd->killed flag to
      evaluate error_code.
      
      Fixed with implementing a scheme suggested and partly implemented at
      time of bug@22725 work-on. error_status is cached immediatly after the
      control leaves the main rows-loop and that instance always corresponds
      to `error' the local of mysql_$query functions. The cached value
      is passed to Query_log_event constructor, not the default thd->killed
      which can be changed in between of the caching and the constructing.
      27436f0b
  9. 25 Oct, 2007 1 commit
  10. 24 Oct, 2007 1 commit
  11. 20 Oct, 2007 1 commit
    • mats@kindahl-laptop.dnsalias.net's avatar
      Bug#31702 (Missing row on slave causes assertion failure under row-based replication): · 24ea15a2
      mats@kindahl-laptop.dnsalias.net authored
      When replicating an update pair (before image, after image) under row-based
      replication, and the before image is not found on the slave, the after image
      was not discared, and was hence read as a before image for the next row.
      Eventually, this lead to an after image being read outside the block of rows
      in the event, causing an assertion to fire.
      
      This patch fixes this by reading the after image in the event that the row
      was not found on the slave, adds some extra debug assertion to catch future
      errors earlier, and also adds a few non-debug checks to prevent reading
      outside the block of the event.
      24ea15a2
  12. 19 Oct, 2007 2 commits
  13. 18 Oct, 2007 1 commit
    • davi@moksha.com.br's avatar
      Bug#21557 entries in the general query log truncated at 1000 characters. · dd135211
      davi@moksha.com.br authored
      The general log write function (general_log_print) uses printf style
      arguments which need to be pre-processed, meaning that the all arguments
      are copied to a single buffer and the problem is that the buffer size is
      constant (1022 characters) but queries can be much larger then this.
      
      The solution is to introduce a new log write function that accepts a
      buffer and it's length as arguments. The function is to be used when
      a formatted output is not required, which is the case for almost all
      query write-to-log calls.
      
      This is a incompatible change with respect to the log format of prepared
      statements.
      dd135211
  14. 13 Oct, 2007 1 commit
  15. 11 Oct, 2007 1 commit
    • mats@kindahl-laptop.dnsalias.net's avatar
      BUG#29549 (Endians: test failures on Solaris): · c4298a3f
      mats@kindahl-laptop.dnsalias.net authored
      Refactoring code to add parameter to pack() and unpack() functions with
      purpose of indicating if data should be packed in little-endian or
      native order. Using new functions to always pack data for binary log
      in little-endian order. The purpose of this refactoring is to allow
      proper implementation of endian-agnostic pack() and unpack() functions.
      
      Eliminating several versions of virtual pack() and unpack() functions
      in favor for one single virtual function which is overridden in
      subclasses.
      
      Implementing pack() and unpack() functions for some field types that
      packed data in native format regardless of the value of the
      st_table_share::db_low_byte_first flag.
      
      The field types that were packed in native format regardless are:
      Field_real, Field_decimal, Field_tiny, Field_short, Field_medium,
      Field_long, Field_longlong, and Field_blob.
      
      Before the patch, row-based logging wrote the rows incorrectly on
      big-endian machines where the storage engine defined its own
      low_byte_first() to be FALSE on big-endian machines (the default
      is TRUE), while little-endian machines wrote the fields in correct
      order. The only known storage engine that does this is NDB. In effect,
      this means that row-based replication from or to a big-endian
      machine where the table was using NDB as storage engine failed if the
      other engine was either non-NDB or on a little-endian machine.
      
      With this patch, row-based logging is now always done in little-endian
      order, while ORDER BY uses the native order if the storage engine
      defines low_byte_first() to return FALSE for big-endian machines.
      
      In addition, the max_data_length() function available in Field_blob
      was generalized to the entire Field hierarchy to give the maximum
      number of bytes that Field::pack() will write.
      c4298a3f
  16. 04 Oct, 2007 1 commit
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug #29309 Incorrect "Seconds_Behind_Master" value in SHOW SLAVE STATUS after FLUSH LOGS · 501cce2b
      aelkin/elkin@koti.dsl.inet.fi authored
      Report claims that Seconds_behind_master behaves unexpectedly. 
      
      Code analysis shows that there is an evident flaw in that treating of FormatDescription event is wrong
      so  that after FLUSH LOGS on slave the Seconds_behind_master's calculation slips and incorrect
      value can be reported to SHOW SLAVE STATUS. 
      Even worse is that the gap between the correct and incorrect deltas grows with time.
      
      Fixed with prohibiting changes to rpl->last_master_timestamp by artifical events (any kind of).
      suggestion as comments is added how to fight with lack of info on the slave side by means of
      new heartbeat feature coming.
      
      The test can not be done ealily fully determistic.
      501cce2b
  17. 24 Sep, 2007 1 commit
  18. 20 Sep, 2007 1 commit
  19. 14 Sep, 2007 1 commit
  20. 07 Sep, 2007 1 commit
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Bug #28430 Failure in replication of innodb partitioned tables on row/mixed format. · a60f7988
      holyfoot/hf@mysql.com/hfmain.(none) authored
      In the ha_partition::position() we don't calculate the number
      of the partition of the record, but use m_last_part value instead,
      relying on that it's previously set by some other call like ::write_row().
      Delete_rows_log_event::do_exec_row() calls find_and_fetch_row(),
      where we used position() + rnd_pos() call for the InnoDB-based PARTITION-ed
      table as there HA_PRIMARY_KEY_REQUIRED_FOR_POSITION enabled.
      
      fixed by introducing new handler::rnd_pos_by_record() method to be
      used for random record-based positioning
      a60f7988
  21. 28 Aug, 2007 2 commits
  22. 27 Aug, 2007 2 commits
  23. 26 Aug, 2007 1 commit
    • rafal@quant.(none)'s avatar
      BUG#21842 (Cluster fails to replicate to innodb or myisam with err 134 · f8b64e17
      rafal@quant.(none) authored
      using TPC-B):
       
      Problem: A RBR event can contain incomplete row data (only key value and
      fields which have been changed). In that case, when the row is unpacked
      into record and written to a table, the missing fields get incorrect NULL
      values leading to master-slave inconsistency.
       
      Solution: Use values found in slave's table for columns which are not given
      in the rows event. The code for writing a single row uses the following 
      algorithm: 
      
      1. unpack row_data into table->record[0],
      2. try to insert record,
      3. if duplicate record found, fetch it into table->record[0],
      4. unpack row_data into table->record[0],
      5. write table->record[0] into the table.
      
      Where row_data is the row as stored in the data area of a rows event. 
      Thus:
      
      a) unpacking of row_data happens at the time when row is written into 
       a table,
      
      b) when unpacking (in step 4), only columns present in row_data are 
       overwritten - all other columns remain as they were found in the table.
       
      Since all data needed for the above algorithm is stored inside 
      Rows_log_event class, functions which locate and write rows are turned 
      into methods of that class.
      
      replace_record()     -> Rows_log_event::write_row()
      find_and_fetch_row() -> Rows_log_event::find_row()
      
      Both methods take row data from event's data buffer - the row being 
      processed is pointed by m_curr_row. They unpack the data as needed into 
      table's record buffers record[0] or record[1]. When row is unpacked, 
      m_curr_row_end is set to point at next row in the data buffer.
      
      Other changes introduced in this changeset:
      
      - Change signature of unpack_row(): don't report errors and don't
      setup table's rw_set here. Errors can happen only when setting default 
      values in prepare_record() function and are detected there.
       
      - In Rows_log_event and derived classes, don't pass arguments to
      the execution primitives (do_...() member functions) but use class
      members instead.
      
      - Move old row handling code into log_event_old.cc to be used by 
      *_rows_log_event_old classes.
      
      Also, a new test rpl_ndb_2other is added which tests basic replication 
      from master using ndb tables to slave storing the same tables using 
      (possibly) different engine (myisam,innodb).
        
      Test is based on existing tests rpl_ndb_2myisam and rpl_ndb_2innodb. 
      However, these tests doesn't work for various reasons and currently are 
      disabled (see BUG#19227).
        
      The new test differs from the ones it is based on as follows:
        
      1. Single test tests replication with different storage engines on slave 
      (myisam, innodb, ndb).
        
      2. Include file extra/rpl_tests/rpl_ndb_2multi_eng.test containing 
      original tests is replaced by extra/rpl_tests/rpl_ndb_2multi_basic.test 
      which doesn't contain tests using partitioned tables as these don't work 
      currently. Instead, it tests replication to a slave which has more or 
      less columns than master.
        
      3. Include file include/rpl_multi_engine3.inc is replaced with 
      include/rpl_multi_engine2.inc. The later differs by performing slightly 
      different operations (updating more than one row in the table) and 
      clearing table with "TRUNCATE TABLE" statement instead of "DELETE FROM" 
      as replication of "DELETE" doesn't work well in this setting.
        
      4. Slave must use option --log-slave-updates=0 as otherwise execution of 
      replication events generated by ndb fails if table uses a different 
      storage engine on slave (see BUG#29569).
      f8b64e17
  24. 16 Aug, 2007 4 commits
  25. 14 Aug, 2007 1 commit
  26. 13 Aug, 2007 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris · e53a73e2
      monty@mysql.com/nosik.monty.fi authored
      Faster thr_alarm()
      Added 'Opened_files' status variable to track calls to my_open()
      Don't give warnings when running mysql_install_db
      Added option --source-install to mysql_install_db
      
      I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems
      index_read()      -> index_read_map()
      index_read_idx()  -> index_read_idx_map()
      index_read_last() -> index_read_last_map()
      e53a73e2
  27. 10 Aug, 2007 1 commit
  28. 08 Aug, 2007 2 commits
    • jani@a88-113-38-195.elisa-laajakaista.fi's avatar
      BUG#30274 (Debug server crashes because mutex isn't initialized): · 283e9529
      Completion patch, since it is possible that Log_event::write_header()
      is called with no current thread.
      
      When starting the server, there is no thread available, but
      MYSQL_BIN_LOG::open() is called to initialize the binary log. The
      function writes a format description log event to the binary log,
      which means that Log_event::write_header() can be called with no
      current thread object available.
      283e9529
    • mats@a88-113-38-195.elisa-laajakaista.fi's avatar
      BUG#30274 (Debug server crashes because mutex isn't initialized): · d52d076f
      Completion patch, since it is possible that Log_event::write_header()
      is called with no current thread.
      
      When starting the server, there is no thread available, but
      MYSQL_BIN_LOG::open() is called to initialize the binary log. The
      function writes a format description log event to the binary log,
      which means that Log_event::write_header() can be called with no
      current thread object available.
      d52d076f
  29. 07 Aug, 2007 2 commits
  30. 01 Aug, 2007 1 commit