1. 02 Feb, 2011 2 commits
    • Tor Didriksen's avatar
      Bug #36022 please log more information about "Sort aborted" queries · b5a44c76
      Tor Didriksen authored
      Write an additional warning message to the server log, 
      explaining why a sort operation is aborted.
      
      The output in mysqld.err will look something like:
      110127 15:07:54 [ERROR] mysqld: Sort aborted: Out of memory (Needed 24 bytes)
      110127 15:07:54 [ERROR] mysqld: Out of sort memory, consider increasing server sort buffer size
      110127 15:07:54 [ERROR] mysqld: Sort aborted: Out of sort memory, consider increasing server sort buffer size
      110127 15:07:54 [ERROR] mysqld: Sort aborted: Incorrect number of arguments for FUNCTION test.f1; expected 0, got 1
      
      If --log-warn=2 is enabled, we output information about host/user/query as well.
      
      
      include/my_sys.h:
        Update comment for ME_NOREFRESH
      mysql-test/include/mtr_warnings.sql:
        Remove global filtering of "Out of sort memory", let each individual test set it instead.
      mysql-test/r/filesort_debug.result:
        New test case.
      mysql-test/r/order_by.result:
        Ignore "Out of memory" for this test.
      mysql-test/t/filesort_debug.test:
        New test case.
      mysql-test/t/order_by.test:
        Ignore "Out of memory" for this test.
      sql/filesort.cc:
        Output an explanation using the error message from the THD Diagnostics_area.
      sql/protocol.cc:
        Do not DBUG_RETURN(function_call_with DBUG_RETURN)
        as it messes up the call stack in the debug output.
      sql/share/errmsg-utf8.txt:
        Change error message for "Out of sort memory"
      sql/unireg.h:
        Remove unused/confusing ERRMAPP macro.
      b5a44c76
    • Tor Didriksen's avatar
      Backport of fix for Bug#52123 · 2b4e3cde
      Tor Didriksen authored
      2b4e3cde
  2. 01 Feb, 2011 3 commits
    • Ole John Aske's avatar
      Fix for bug#58490, 'Incorrect result in multi level OUTER JOIN · cafb6e8a
      Ole John Aske authored
      in combination with IS NULL'
            
      As this bug is a duplicate of bug#49322, it also includes test cases
      covering this bugreport
            
      Qualifying an OUTER JOIN with the condition 'WHERE <column> IS NULL',
      where <column> is declared as 'NOT NULL' causes the
      'not_exists_optimize' to be enabled by the optimizer.
            
      In evaluate_join_record() the 'not_exists_optimize' caused
      'NESTED_LOOP_NO_MORE_ROWS' to be returned immediately
      when a matching row was found.
            
      However, as the 'not_exists_optimize' is derived from
      'JOIN_TAB::select_cond', the usual rules for condition guards
      also applies for 'not_exist_optimize'. It is therefore incorrect
      to check 'not_exists_optimize' without ensuring that all guards
      protecting it is 'open'.
            
      This fix uses the fact that 'not_exists_optimize' is derived from
      a 'is_null' predicate term in 'tab->select_cond'. Furthermore,
      'is_null' will evaluate to 'false' for any 'non-null' rows
      once all guards protecting the is_null is open.
            
      We can use this knowledge as an implicit guard check for the
      'not_exists_optimize' by moving 'if (...not_exists_optimize)'
      inside the handling of 'select_cond==false'. It will then
      not take effect before its guards are open.
            
      We also add an assert which requires that a
      'not_exists_optimize' always comes together with
      a select_cond. (containing 'is_null').
      cafb6e8a
    • Ole John Aske's avatar
      Merge · e2b9b074
      Ole John Aske authored
      e2b9b074
    • Ole John Aske's avatar
      Fix for bug#57030: ('BETWEEN' evaluation is incorrect') · 24cd59d6
      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.
      24cd59d6
  3. 31 Jan, 2011 9 commits
  4. 30 Jan, 2011 4 commits
  5. 29 Jan, 2011 5 commits
  6. 28 Jan, 2011 10 commits
    • Bjorn Munch's avatar
      Bug #59148 'INSTALL PLUGIN rpl_semi_sync_master' fails in release build with debug binaries · b51ab5e6
      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
      b51ab5e6
    • Mattias Jonsson's avatar
      merge · 2a6e34f2
      Mattias Jonsson authored
      2a6e34f2
    • Mattias Jonsson's avatar
      minor fix of copyright header · 74efe8c3
      Mattias Jonsson authored
      74efe8c3
    • Mattias Jonsson's avatar
      merge · a2f39d9d
      Mattias Jonsson authored
      a2f39d9d
    • Alfranio Correia's avatar
      BUG#59338 Inconsistency in binlog for statements that don't change any rows STATEMENT SBR · 6f12ed4a
      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.
      6f12ed4a
    • John H. Embretsen's avatar
      Null-merge from mysql-5.1 · 2aafc476
      John H. Embretsen authored
      2aafc476
    • Jimmy Yang's avatar
      f173c706
    • Jimmy Yang's avatar
      7b1b224c
    • Jimmy Yang's avatar
      Fix Bug #59465 btr_estimate_number_of_different_key_vals use incorrect offset · 2c53b74b
      Jimmy Yang authored
      for external_size
            
      rb://581 approved by Marko
      2c53b74b
    • Alfranio Correia's avatar
      BUG#55675 rpl.rpl_log_pos fails sporadically with error binlog truncated in the middle · ce326166
      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.
      ce326166
  7. 27 Jan, 2011 7 commits