1. 07 Feb, 2011 2 commits
    • Ole John Aske's avatar
      Fix for bug#59308: Incorrect result for SELECT DISTINCT <col>... ORDER BY <col> DESC. · 3e533efa
      Ole John Aske authored
            
      Also fix bug#59110: Memory leak of QUICK_SELECT_I allocated memory.
      Includes Jørgen Lølands review comments.
            
      Root cause of these bugs are that test_if_skip_sort_order() decided to
      revert the 'skip_sort_order' descision (and use filesort) after the
      query plan has been updated to reflect a 'skip' of the sort order.
            
      This might happen in 'check_reverse_order:' if we have a 
      select->quick which could not be made descending by appending 
      a QUICK_SELECT_DESC. ().
            
      The original 'save_quick' was then restored after the QEP has been modified,
      which caused:
            
        - An incorrect 'precomputed_group_by= TRUE' may have been set, 
          and not reverted, as part of the already modifified QEP (Bug#59308)
        - A 'select->quick' might have been created which we fail to delete (bug#59110).
            
      This fix is a refactorication of test_if_skip_sort_order() where all logic
      related to modification of QEP (controlled by argument 'bool no_changes'), is
      moved to the end of test_if_skip_sort_order(), and done after *all* 'test_if_skip'
      checks has been performed - including the 'check_reverse_order:' checks.
            
      The refactorication above contains now intentional changes to the logic which 
      has been moved to the end of the function.
            
      Furthermore, a smaller part of the fix address the handling of the 
      select->quick objects which may already exists when we call 
      'test_if_skip_sort_order()' (save_quick) -and
      new select->quick's created during test_if_skip_sort_order():
            
        - Before new select->quick may be created by calling ::test_quick_select(), we
          set 'select->quick= 0' to avoid that ::test_quick_select() prematurely
          delete the save_quick's. (After this call we may have both a 'save_quick' 
          and 'select->quick')
            
        - All returns from ::test_if_skip_sort_order() where we may have both a
          'save_quick' and a 'select->quick' has been changed to goto's to the
          exit points 'skiped_sort_order:' or 'need_filesort:' where we
          decide which of the QUICK_SELECT's to keep, and delete the other.
      3e533efa
    • Vinay Fisrekar's avatar
      Bug#59955 - engines/funcs/ps_string_not_null test needs better cleanup · 4a20a603
      Vinay Fisrekar authored
      Correcting clean up command at the start of test.
      4a20a603
  2. 05 Feb, 2011 1 commit
    • Dmitry Shulga's avatar
      Fixed bug#57450 - mysql client enter in an infinite loop · 2f0ba4c3
      Dmitry Shulga authored
      if the standard input is a directory.
      
      The problem is that mysql monitor try to read from stdin without
      checking input source type.
      
      The solution is to stop reading data from standard input if a call
      to read(2) failed.
      
      A new test case was added into mysql.test.
      2f0ba4c3
  3. 04 Feb, 2011 2 commits
  4. 03 Feb, 2011 1 commit
    • Luis Soares's avatar
      BUG#59147: rpl_circular_for_4_hosts fails sporadically · 64b0591d
      Luis Soares authored
            
      There is one part of the test case that needs to break
      and re-establish the circular topology. For this the test
      stops the slave threads on a couple of servers and restarts
      them with START SLAVE. However, no check is done on the
      status of the IO or SQL threads before proceeding with
      the subsequent commands.
            
      Because rpl_only_running_threads is set to 1 this can lead
      to silently not syncing all slave threads as expected, 
      ultimately resulting in unexpected results (and consequently
      on a failing test run).
            
      We fix this by replacing the START SLAVE instructions with
      calls to --source include/start_slave.inc, which will wait
      for the slave threads to be running (show 'Yes' in 
      Slave_IO|SQL_Running fields of SHOW SLAVE STATUS) before 
      proceeding. Additionally, we change rpl_sync.inc to make the
      IO thread report that it is running when its running status
      is any other than 'No'.
      64b0591d
  5. 02 Feb, 2011 5 commits
    • Georgi Kodinov's avatar
      merge · 63a40fe6
      Georgi Kodinov authored
      63a40fe6
    • Georgi Kodinov's avatar
      6954b672
    • Georgi Kodinov's avatar
      merge to 5.1. · ac3243c8
      Georgi Kodinov authored
      ac3243c8
    • Georgi Kodinov's avatar
      Fixes for Bug #55755 and Bug #52315 part 2 · 59f68983
      Georgi Kodinov authored
      Bug #55755 : Date STD variable signness breaks server on FreeBSD and OpenBSD
      
      * Added a check to configure on the size of time_t
      * Created a macro to check for a valid time_t that is safe to use with datetime 
        functions and store in TIMESTAMP columns.
      * Used the macro consistently instead of the ad-hoc checks introduced by 52315
      * Fixed compliation warnings on platforms where the size of time_t is smaller than
        the size of a long (e.g. OpenBSD 4.8 64 amd64).
      
      Bug #52315: utc_date() crashes when system time > year 2037
      
      * Added a correct check for the timestamp range instead of just variable size check to
      SET TIMESTAMP.
      * Added overflow checking before converting to time_t. 
      * Using a correct localized error message in this case instead of the generic error.
      * Added a test suite.
      * fixed the checks so that they check for unsigned time_t as well. Used the checks 
        consistently across the source code.
      * fixed the original test case to expect the new error code.
      59f68983
    • Dmitry Lenev's avatar
      Fix for bug #58650 "Failing assertion: primary_key_no == -1 || · 3473329d
      Dmitry Lenev authored
      primary_key_no == 0".
      
      Attempt to create InnoDB table with non-nullable column of
      geometry type having an unique key with length 12 on it and
      with some other candidate key led to server crash due to
      assertion failure in both non-debug and debug builds.
      
      The problem was that such a non-candidate key could have
      been sorted as the first key in table/.FRM, before any legit
      candidate keys. This resulted in assertion failure in InnoDB
      engine which assumes that primary key should either be the
      first key in table/.FRM or should not exist at all.
      
      The reason behind such an incorrect sorting was an wrong
      value of Create_field::key_length member for geometry field
      (which was set to its pack_length == 12) which confused code
      in mysql_prepare_create_table(), so it would skip marking
      such key as a key with partial segments.
      
      This patch fixes the problem by ensuring that this member
      gets the same value of Create_field::key_length member as 
      for other blob fields (from which geometry field class is
      inherited), and as result unique keys on geometry fields
      are correctly marked as having partial segments.
      3473329d
  6. 01 Feb, 2011 1 commit
    • Ole John Aske's avatar
      Fix for bug#57030: ('BETWEEN' evaluation is incorrect') · c8de3bba
      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.
      c8de3bba
  7. 31 Jan, 2011 4 commits
  8. 30 Jan, 2011 1 commit
  9. 29 Jan, 2011 1 commit
    • John H. Embretsen's avatar
      Fix for Bug#56817 - mysqlhotcopy tests fail when DBI and DBD-mysql perl modules are not found · 23887668
      John H. Embretsen authored
      Third updated patch - this version also includes copyright notice in added Perl script.
      This patch implements a check for such modules at runtime. If modules are not found or unable to load, the test is skipped with 
      the following message:
                  
                  [ skipped ]  Test needs Perl modules DBI and DBD::mysql
                  
      Checks are done via a helper Perl script which looks for the module in a runtime environment that is as similar to that of the 
      mysqlhotcopy script as possible (thus not intended for Windows environments at this time).
      The helper script tells mysql-test about the result by writing information to a temporary file that is later read by mysql-test.
      See comments in added files (have_dbi_dbd-mysql.inc and checkDBI_DBD-mysql.pl) for details.
      The patch also removes the mysqlhotcopy tests from the list of disabled tests.
      23887668
  10. 28 Jan, 2011 4 commits
    • Mattias Jonsson's avatar
      minor fix of copyright header · 70b0991b
      Mattias Jonsson authored
      70b0991b
    • Alfranio Correia's avatar
      BUG#59338 Inconsistency in binlog for statements that don't change any rows STATEMENT SBR · 66abb3d1
      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.
      66abb3d1
    • Jimmy Yang's avatar
      Fix Bug #59465 btr_estimate_number_of_different_key_vals use incorrect offset · a9f1c9f3
      Jimmy Yang authored
      for external_size
            
      rb://581 approved by Marko
      a9f1c9f3
    • Alfranio Correia's avatar
      BUG#55675 rpl.rpl_log_pos fails sporadically with error binlog truncated in the middle · 5a0af479
      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.
      5a0af479
  11. 27 Jan, 2011 7 commits
  12. 26 Jan, 2011 8 commits
  13. 25 Jan, 2011 3 commits