1. 01 Feb, 2011 2 commits
    • Ole John Aske's avatar
      Merge · 4b8888f6
      Ole John Aske authored
      4b8888f6
    • Ole John Aske's avatar
      Fix for bug#57030: ('BETWEEN' evaluation is incorrect') · 59269b1d
      Ole John Aske authored
                  
      Root cause for this bug is that the optimizer try to detect&
      optimize the special case:
            
      '<field>  BETWEEN c1 AND c1' and handle this as the condition '<field>  = c1'
                  
      This was implemented inside add_key_field(.. *field, *value[]...)
      which assumed field to refer key Field, and value[] to refer a [low...high]
      constant pair. value[0] and value[1] was then compared for equality.
                  
      In a 'normal' BETWEEN condition of the form '<field>  BETWEEN val1 and val2' the
      BETWEEN operation is represented with an argementlist containing the
      values [<field>, val1, val2] - add_key_field() is then called with
      parameters field=<field>, *value=val1.
                  
      However, if the BETWEEN predicate specified:
                  
       1)  '<const1>  BETWEEN<const2>  AND<field>
                  
      the 'field' and 'value' arguments to add_key_field() had to be swapped.
      This was implemented by trying to cheat add_key_field() to handle it like:
                  
       2) '<const1>  GE<const2>  AND<const1>  LE<field>'
                  
      As we didn't really replace the BETWEEN operation with 'ge' and 'le',
      add_key_field() still handled it as a 'BETWEEN' and compared the (swapped)
      arguments<const1>  and<const2>  for equality. If they was equal, the
      condition 1) was incorrectly 'optimized' to:
                  
       3) '<field>  EQ <const1>'
                  
      This fix moves this optimization of '<field>  BETWEEN c1 AND c1' into
      add_key_fields() which then calls add_key_equal_fields() to collect 
      key equality / comparison for the key fields in the BETWEEN condition.
      59269b1d
  2. 31 Jan, 2011 9 commits
  3. 30 Jan, 2011 4 commits
  4. 29 Jan, 2011 5 commits
  5. 28 Jan, 2011 10 commits
    • Bjorn Munch's avatar
      Bug #59148 'INSTALL PLUGIN rpl_semi_sync_master' fails in release build with debug binaries · 74f773b4
      Bjorn Munch authored
      Do as mysqld_safe: if running mysqld-debug, plugins are in debug subdirs
      NB mtr --debug won't work in this context until 47141 is fixed
      Also moved read_plugin_defs; no point running this in all worker threads
      74f773b4
    • Mattias Jonsson's avatar
      merge · 70e3313e
      Mattias Jonsson authored
      70e3313e
    • Mattias Jonsson's avatar
      minor fix of copyright header · d83706bc
      Mattias Jonsson authored
      d83706bc
    • Mattias Jonsson's avatar
      merge · bede87d3
      Mattias Jonsson authored
      bede87d3
    • Alfranio Correia's avatar
      BUG#59338 Inconsistency in binlog for statements that don't change any rows STATEMENT SBR · 8ce9b992
      Alfranio Correia authored
      In SBR, if a statement does not fail, it is always written to the binary
      log, regardless if rows are changed or not. If there is a failure, a
      statement is only written to the binary log if a non-transactional (.e.g.
      MyIsam) engine is updated.
      
      INSERT ON DUPLICATE KEY UPDATE and INSERT IGNORE were not following the
      rule above and were not written to the binary log, if then engine was
      Innodb.
      
      mysql-test/extra/rpl_tests/rpl_insert_duplicate.test:
        Added test case.
      mysql-test/extra/rpl_tests/rpl_insert_ignore.test:
        Updated test case.
      mysql-test/include/commit.inc:
        Updated test case as the calls to the binary log have changed
        for INSERT ON DUPLICATE and INSERT IGNORE.
      mysql-test/r/commit_1innodb.result:
        Updated result file.
      mysql-test/suite/rpl/r/rpl_insert_duplicate.result:
        Added test case.
      mysql-test/suite/rpl/r/rpl_insert_ignore.result:
        Updated result file.
      mysql-test/suite/rpl/t/rpl_insert_duplicate.test:
        Added test case.
      mysql-test/suite/rpl/t/rpl_insert_ignore.test:
        Improved test case.
      8ce9b992
    • John H. Embretsen's avatar
      Null-merge from mysql-5.1 · cbf2f80d
      John H. Embretsen authored
      cbf2f80d
    • Jimmy Yang's avatar
      b448b5d5
    • Jimmy Yang's avatar
      df13ee2e
    • Jimmy Yang's avatar
      Fix Bug #59465 btr_estimate_number_of_different_key_vals use incorrect offset · 71e8043b
      Jimmy Yang authored
      for external_size
            
      rb://581 approved by Marko
      71e8043b
    • Alfranio Correia's avatar
      BUG#55675 rpl.rpl_log_pos fails sporadically with error binlog truncated in the middle · 235e10d9
      Alfranio Correia authored
      There are two calls to read_log_event() on master in mysql_binlog_send().
      Each call reads 19 bytes in this test case and the error of the second
      read_log_event() is reported to the slave.
      
      The second read_log_event() starts from position 94 (75 + 19) to 113
      (75 + 19 + 19). Usually, there are two events in the binary log:
      
          . 0   - 3   - Header
          . 4   - 105 - Format Descriptor Event
          . 106 - 304 - Query Event
      
      and both reads fail because operations are reading from invalid positions
      as expected.
      
      However, mysql_binlog_send() does not use the same IO_CACHE that is used to
      write into binary log (i.e. mysql_bin_log.log_file) for the hot binary log.
      It opens the binary log file directly by calling open_binlog() and creates a
      separated IO_CACHE. So there is a possibly that after a master has flushed
      the binary log file, the content has been cached by the filesystem, and has
      not updated the disk file. If this happens, then a slave will only see part
      of the file, and thus the second read_log_event() will report event truncated
      error.
      
      To fix the problem, if the first read_log_event() has failed, we ensure that
      the second one will try to read from the same position.
      235e10d9
  6. 27 Jan, 2011 10 commits