1. 10 Feb, 2011 3 commits
  2. 09 Feb, 2011 8 commits
  3. 08 Feb, 2011 7 commits
  4. 07 Feb, 2011 8 commits
    • Bjorn Munch's avatar
      merge 47141,59979 · 1e7fac2d
      Bjorn Munch authored
      1e7fac2d
    • Vasil Dimov's avatar
      Backport the fix for Bug#59875 Valgrind warning in buf0buddy.c from 5.5 · b7cc4aa0
      Vasil Dimov authored
      This warning also happens in 5.1 with a slightly different codepath.
      b7cc4aa0
    • Dmitry Lenev's avatar
      Merged fix for bug #36544 "DROP USER does not remove stored · 03e27ac1
      Dmitry Lenev authored
      function privileges" into 5.5 tree. Did after-merge fixes.
      03e27ac1
    • Bjorn Munch's avatar
      Bug #59979 Add mtr option to run debug server, but without turning on debug · 3cde3f30
      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
      3cde3f30
    • Dmitry Lenev's avatar
      Fix for bug#36544 "DROP USER does not remove stored function · e960abc7
      Dmitry Lenev authored
      privileges".
      
      The first problem was that DROP USER didn't properly remove privileges 
      on stored functions from in-memory structures. So the dropped user
      could have called stored functions on which he had privileges before
      being dropped while his connection was still around.
      Even worse if a new user with the same name was created he would
      inherit privileges on stored functions from the dropped user.
      Similar thing happened with old user name and function privileges
      during RENAME USER.
      
      This problem stemmed from the fact that the handle_grant_data() function
      which handled DROP/RENAME USER didn't take any measures to update
      in-memory hash with information about function privileges after
      updating them on disk.
      
      This patch solves this problem by adding code doing just that.
      
      The second problem was that RENAME USER didn't properly update in-memory
      structures describing table-level privileges and privileges on stored 
      procedures. As result such privileges could have been lost after a rename
      (i.e. not associated with the new name of user) and inherited by a new
      user with the same name as the old name of the original user.
      
      This problem was caused by code handling RENAME USER in
      handle_grant_struct() which [sic!]:
      a) tried to update wrong (tables) hash when updating stored procedure
         privileges for new user name.
      b) passed wrong arguments to function performing the hash update and
         didn't take into account the way in which such update could have
         changed the order of the hash elements.
      
      This patch solves this problem by ensuring that a) the correct hash
      is updated, b) correct arguments are used for the hash_update()
      function and c) we take into account possible changes in the order
      of hash elements.
      e960abc7
    • 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
    • Vasil Dimov's avatar
      Use fun:* instead of obj:*/libz.so* because when the bundled zlib is · 098a2ee8
      Vasil Dimov authored
      used (--with-zlib-dir=bundled) then there is no libz.so involved.
      098a2ee8
    • 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
  5. 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
  6. 04 Feb, 2011 5 commits
  7. 03 Feb, 2011 2 commits
    • Joerg Bruehe's avatar
      Fix Bug #56581 RPM scripts use hardcoded datadir location · 796672c4
      Joerg Bruehe authored
      When fixing the 27072 bug, the shell snippets running before/after
      a RPM upgrade got expanded to look at files in the data directory
      and at the PID file.
      In this expansion, the standard locations were used.
      
      There are users who configure their installations to use non-standard
      locations for the data directory, the PID file, and other objects.
      For these users, the fix of 27072 did not work.
      As a result, the fact that a server was running at upgrade start was
      not noticed, and the new server was not started after the upgrade.
      
      With this patch, the shell snippets now try to get these locations
      from "my_print_defaults" before falling back to the defaults.
      Now, the fact that the old server is running is again noticed (even
      with non-standard locations), and the new server is started.
      
      Also, the upgrade log is written to the correct data directory.
      796672c4
    • 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
  8. 02 Feb, 2011 6 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
    • Marko Mäkelä's avatar
      Bug #55284 diagnostics: Introduce UNIV_BLOB_LIGHT_DEBUG, enabled by UNIV_DEBUG · e67169ee
      Marko Mäkelä authored
      btr_rec_get_field_ref_offs(), btr_rec_get_field_ref(): New functions.
      Get the pointer to an externally stored field.
      
      btr_cur_set_ownership_of_extern_field(): Assert that the BLOB has not
      already been disowned.
      
      btr_store_big_rec_extern_fields(): Rename to
      btr_store_big_rec_extern_fields_func() and add the debug parameter
      update_in_place. All pointers to externally stored columns in the
      record must either be zero or they must be pointers to inherited
      columns, owned by this record or an earlier record version. For any
      BLOB that is stored, the BLOB pointer must previously have been
      zero. When the function completes, all BLOB pointers must be nonzero
      and owned by the record.
      
      rb://549 approved by Jimmy Yang
      e67169ee
    • 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