1. 08 Feb, 2011 1 commit
  2. 07 Feb, 2011 10 commits
    • Bjorn Munch's avatar
      null upmerge · 31ef650e
      Bjorn Munch authored
      31ef650e
    • Bjorn Munch's avatar
      merge 47141,59979 · 76979f66
      Bjorn Munch authored
      76979f66
    • Bjorn Munch's avatar
      merge 47141,59979 · 285c7d04
      Bjorn Munch authored
      285c7d04
    • Bjorn Munch's avatar
      upmerged and adapted 59979 · 44c74841
      Bjorn Munch authored
      44c74841
    • Bjorn Munch's avatar
      Bug #59979 Add mtr option to run debug server, but without turning on debug · 114ac525
      Bjorn Munch authored
      Added --debug-server and use $opt_debug_server where appropriate
      Let --debug imply --debug-server
      When merging to 5.5, must adapt fix for 59148
      Oops, set debug => debug-server too late, fixed
      114ac525
    • Tor Didriksen's avatar
      Bug #59632 Assertion failed: arg_length > length · dcd9f246
      Tor Didriksen authored
      The problem was overflow in max_length when we tried to des_decrypt()
      something which is not the output of des_encrypt()
      
      
      mysql-test/r/ssl_and_innodb.result:
        New test case.
      mysql-test/t/ssl_and_innodb.test:
        New test case.
      sql/item_strfunc.h:
        Do not subtract the encrypt overhead (9U) if args[0] has length < 9
        (In unsigned arithmetic, (1-9) becomes a very large number)
      dcd9f246
    • Ole John Aske's avatar
      cee1b3dd
    • Ole John Aske's avatar
      Fix for bug#59308: Incorrect result for SELECT DISTINCT <col>... ORDER BY <col> DESC. · 221ce922
      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.
      221ce922
    • Vinay Fisrekar's avatar
      bzr merger from mysql-5.1 to mysql-5.5 · 2f3fdbcf
      Vinay Fisrekar authored
      Bug#59955 - engines/funcs/ps_string_not_null test needs better cleanup
      2f3fdbcf
    • Vinay Fisrekar's avatar
      Bug#59955 - engines/funcs/ps_string_not_null test needs better cleanup · e29b40f8
      Vinay Fisrekar authored
      Correcting clean up command at the start of test.
      e29b40f8
  3. 05 Feb, 2011 2 commits
    • Dmitry Shulga's avatar
      Auto-merge from mysql-5.1 for bug#57450. · d197051e
      Dmitry Shulga authored
      d197051e
    • Dmitry Shulga's avatar
      Fixed bug#57450 - mysql client enter in an infinite loop · 980868eb
      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.
      
      client/my_readline.h:
        Data members error and truncated was added to LINE_BUFFER structure.
        These data members used instead of out parameters in functions
        batch_readline, intern_read_line.
      client/mysql.cc:
        read_and_execute() was modified: set status.exit_status to 1
        when the error occured while reading the next command line in
        non-interactive mode. Also the value of the truncated attribute
        of structure LINE_BUFF is taken into account only for non-iteractive mode.
      client/readline.cc:
        intern_read_line() was modified: cancel reading from input if
        fill_buffer() returns -1, e.g. if call to read failed.
        batch_readline was modified: set the error data member of LINE_BUFFER
        structure to value of my_errno when system error happened during call
        to my_read/my_realloc.
      mysql-test/t/mysql.test:
        Test for bug#57450 was added.
      980868eb
  4. 04 Feb, 2011 10 commits
  5. 03 Feb, 2011 1 commit
    • Luis Soares's avatar
      BUG#59147: rpl_circular_for_4_hosts fails sporadically · cb10771f
      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'.
      cb10771f
  6. 02 Feb, 2011 11 commits
    • Georgi Kodinov's avatar
      merge · 9abc2aad
      Georgi Kodinov authored
      9abc2aad
    • Georgi Kodinov's avatar
      merge · fe145b09
      Georgi Kodinov authored
      fe145b09
    • Georgi Kodinov's avatar
      merge · a265fde6
      Georgi Kodinov authored
      a265fde6
    • Georgi Kodinov's avatar
      0a8419df
    • Georgi Kodinov's avatar
      merge to 5.1. · 72ae1d65
      Georgi Kodinov authored
      72ae1d65
    • Georgi Kodinov's avatar
      Fixes for Bug #55755 and Bug #52315 part 2 · a70c34bf
      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.
      a70c34bf
    • Dmitry Lenev's avatar
      Merged fix for bug #58650 "Failing assertion: · d98270e1
      Dmitry Lenev authored
      primary_key_no == -1 || primary_key_no == 0"
      with recent changes from mysql-5.5 tree.
      d98270e1
    • Dmitry Lenev's avatar
      Merged fix for bug #58650 "Failing assertion: · 5c3151e4
      Dmitry Lenev authored
      primary_key_no == -1 || primary_key_no == 0"
      into mysql-5.5 tree.
      5c3151e4
    • Dmitry Lenev's avatar
      Fix for bug #58650 "Failing assertion: primary_key_no == -1 || · e805a0fd
      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.
      
      
      mysql-test/include/gis_keys.inc:
        Added test case for bug #58650 "Failing assertion:
        primary_key_no == -1 || primary_key_no == 0".
      mysql-test/r/gis.result:
        Added test case for bug #58650 "Failing assertion:
        primary_key_no == -1 || primary_key_no == 0".
      mysql-test/suite/innodb/r/innodb_gis.result:
        Added test case for bug #58650 "Failing assertion:
        primary_key_no == -1 || primary_key_no == 0".
      mysql-test/suite/innodb_plugin/r/innodb_gis.result:
        Added test case for bug #58650 "Failing assertion:
        primary_key_no == -1 || primary_key_no == 0".
      sql/field.cc:
        Changed Create_field::create_length_to_internal_length() to
        correctly set Create_field::key_length member for geometry
        fields. Similar to the blob types key_length for such fields
        should be the same as length and not field's packed length
        (which is always 12 for geometry).
        
        As result of this change code handling table creation now
        always correctly identifies btree/unique keys on geometry
        fields as partial keys, so such keys can't be erroneously
        treated as candidate keys and sorted in keys array in .FRM
        before legit candidate keys.
        
        This fixes bug #58650 "Failing assertion: primary_key_no ==
        -1 || primary_key_no == 0" in which incorrect candidate key
        sorting led to assertion failure in InnoDB code.
      e805a0fd
    • Tor Didriksen's avatar
      Bug #36022 please log more information about "Sort aborted" queries · c711ce67
      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.
      c711ce67
    • Tor Didriksen's avatar
      Backport of fix for Bug#52123 · b503d77d
      Tor Didriksen authored
      b503d77d
  7. 01 Feb, 2011 3 commits
    • Ole John Aske's avatar
      Fix for bug#58490, 'Incorrect result in multi level OUTER JOIN · ed74edad
      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').
      ed74edad
    • 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
  8. 31 Jan, 2011 2 commits