1. 11 Mar, 2011 1 commit
  2. 24 Feb, 2011 1 commit
    • Magne Mahre's avatar
      Bug#11767480 - SPATIAL INDEXES ON NON-SPATIAL COLUMNS CAUSE CRASHES. · 27166fc6
      Magne Mahre authored
            
      This is a backport of the patch for MySQL Bug#50574.
            
      Adding a SPATIAL INDEX on non-geometrical columns caused a
      segmentation fault when the table was subsequently 
      inserted into.
                  
      A test was added in mysql_prepare_create_table to explicitly
      check whether non-geometrical columns are used in a
      spatial index, and throw an error if so.
            
      For MySQL 5.5 and later, a new and more meaningful error 
      message was introduced.  For 5.1, we (re-)use an existing
      error code.
      27166fc6
  3. 11 Feb, 2011 1 commit
  4. 10 Feb, 2011 3 commits
  5. 09 Feb, 2011 8 commits
  6. 08 Feb, 2011 7 commits
  7. 07 Feb, 2011 8 commits
    • Bjorn Munch's avatar
      merge 47141,59979 · 285c7d04
      Bjorn Munch authored
      285c7d04
    • Vasil Dimov's avatar
      Backport the fix for Bug#59875 Valgrind warning in buf0buddy.c from 5.5 · fe403949
      Vasil Dimov authored
      This warning also happens in 5.1 with a slightly different codepath.
      fe403949
    • Dmitry Lenev's avatar
      Merged fix for bug #36544 "DROP USER does not remove stored · f74fd118
      Dmitry Lenev authored
      function privileges" into 5.5 tree. Did after-merge fixes.
      f74fd118
    • 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
    • Dmitry Lenev's avatar
      Fix for bug#36544 "DROP USER does not remove stored function · b169b8d8
      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.
      
      mysql-test/r/grant.result:
        Added test coverage for bug#36544 "DROP USER does not remove stored
        function privileges".
      mysql-test/suite/funcs_1/r/innodb_storedproc_06.result:
        Since after fixing bug#36544 "DROP USER does not remove stored function
        privileges" in-memory structures are correctly updated by DROP USER,
        DROP FUNCTION performed after DROP USER for its definer no longer
        produces unwarranted warning/error messages.
      mysql-test/suite/funcs_1/r/memory_storedproc_06.result:
        Since after fixing bug#36544 "DROP USER does not remove stored function
        privileges" in-memory structures are correctly updated by DROP USER,
        DROP FUNCTION performed after DROP USER for its definer no longer
        produces unwarranted warning/error messages.
      mysql-test/suite/funcs_1/r/myisam_storedproc_06.result:
        Since after fixing bug#36544 "DROP USER does not remove stored function
        privileges" in-memory structures are correctly updated by DROP USER,
        DROP FUNCTION performed after DROP USER for its definer no longer
        produces unwarranted warning/error messages.
      mysql-test/t/grant.test:
        Added test coverage for bug#36544 "DROP USER does not remove stored
        function privileges".
      sql/sql_acl.cc:
        Changed handle_grant_data() to also update hash with function 
        privileges. This allows DROP/RENAME USER correctly keep this 
        in-memory structure up-to-date.
        
        To do this extended handle_grant_struct() to support updating of this
        hash. In addition fixed code in this function which is responsible for 
        handling of column and routine hashes during RENAME USER, ensured that
        we correctly update these hashes after changing user name and that we
        don't skip elements while iterating through the hash and doing updates.
      b169b8d8
    • 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
    • Vasil Dimov's avatar
      Use fun:* instead of obj:*/libz.so* because when the bundled zlib is · 165ed4f1
      Vasil Dimov authored
      used (--with-zlib-dir=bundled) then there is no libz.so involved.
      165ed4f1
    • 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
  8. 05 Feb, 2011 1 commit
    • 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
  9. 04 Feb, 2011 5 commits
    • Luis Soares's avatar
    • Bjorn Munch's avatar
      merge from 5.1 main · bb3e48c2
      Bjorn Munch authored
      bb3e48c2
    • Bjorn Munch's avatar
      Bug #47141 "mysqltest" breaks because it tries to act on a debug option which is disabled · cd51cbf1
      Bjorn Munch authored
      Replace --debug with --loose-debug to prevent failure exit
      Update: added workaround for 50627, skip all debugging of mysqlbinlog
      cd51cbf1
    • Vasil Dimov's avatar
      Fix Bug#59874 Valgrind warning in InnoDB compression code · 5082c4d1
      Vasil Dimov authored
      Add suppressions for a bogus valgrind warnings.
      5082c4d1
    • Dmitry Shulga's avatar
      Fixed bug#58026 - massive recursion and crash in regular expression · 378091e4
      Dmitry Shulga authored
      handling.
      
      The problem was that parsing of nested regular expression involved
      recursive calls. Such recursion didn't take into account the amount of
      available stack space, which ended up leading to stack overflow crashes.
      
      mysql-test/t/not_embedded_server.test:
        Added test for bug#58026.
      regex/my_regex.h:
        added pointer to function as last argument of my_regex_init() for check
        enough memory in stack.
      regex/regcomp.c:
        p_ere() was modified: added call to function for check enough memory
        in stack. Function for check available stack space specified by
        global variable my_regex_enough_mem_in_stack. This variable set to
        NULL for embedded mysqld and to a pointer to function
        check_enough_stack_size otherwise.
      regex/reginit.c:
        my_regex_init was modified: pass a pointer to a function for check
        enough memory in stack space. Reset this pointer to NULL in my_regex_end.
      sql/mysqld.cc:
        Added function check_enough_stack_size() for check enough memory in stack.
        Passed this function as second argument to my_regex_init. For embedded 
        mysqld passed NULL as second argument.
      378091e4
  10. 03 Feb, 2011 2 commits
    • Joerg Bruehe's avatar
      Fix Bug #56581 RPM scripts use hardcoded datadir location · 106e5900
      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.
      
      support-files/mysql.spec.sh:
        See the global comment for the purpose of this change.
        
        In tests on SuSE 11, it was found necessary to use the full path name
        of "my_print_defaults", it seems $PATH die not include "/usr/bin".
      106e5900
    • 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
  11. 02 Feb, 2011 3 commits