1. 31 Mar, 2011 1 commit
    • Georgi Kodinov's avatar
      Merged the fix for bug #11936829 to 5.5.11 release · 6d849b93
      Georgi Kodinov authored
      Bug #11936829: DIFF. BETWEEN MYSQL.USER (AUTHENTICATION_STRING) IN 
        FRESH AND UPGRADED 5.5.11
                   
      There was no modification for pre 5.5.11 builds that had 
      authentication_string.  Thus the column was not upgraded 
      by mysql_upgrade.
                               
      Fixed by adding an ALTER TABLE MODIFY to update an existing 
      column to the latest type version.
                                           
      Test suite added.
      6d849b93
  2. 22 Mar, 2011 2 commits
  3. 18 Mar, 2011 9 commits
  4. 17 Mar, 2011 10 commits
  5. 16 Mar, 2011 9 commits
  6. 15 Mar, 2011 6 commits
    • Serge Kozlov's avatar
      bug#58525 postfix · 62e83ad8
      Serge Kozlov authored
      62e83ad8
    • Sven Sandberg's avatar
      BUG#11872422: rpl_slave_load_remove_tmpfile fails sporadically in pb2 · 9cb096ac
      Sven Sandberg authored
      Problem: the test failed because errors were found in the error log.
      The test case contains suppressions for an old version of the error message,
      but the format of the error message has changed without updating the suppression.
      Fix: Update the suppression. Also small fixes to improve the test.
      
      
      mysql-test/suite/rpl/r/rpl_slave_load_remove_tmpfile.result:
        update result file
      mysql-test/suite/rpl/t/rpl_slave_load_remove_tmpfile-slave.opt:
        Use variables instead of .opt files to avoid server restarts.
      mysql-test/suite/rpl/t/rpl_slave_load_remove_tmpfile.test:
        1. To fix the bug, we update the regular expression in mtr.add_suppression
           so that it matches the real error text.
        2. Use wait_for_slave_sql_error.inc when we wait for an error.
           This makes the test easier to understand and will produce better
           debug info if the test fails.
        3. Use server variables instead of command line options to set
           the @@GLOBAL.DEBUG variable. This avoids server restarts when
           running the test suite.
        4. Clarify the comment at the top of the file and add bug reference.
      9cb096ac
    • Dmitry Shulga's avatar
      Manual merge from mysql-5.1 for Bug#11764168 (56976: Severe denial · feb6d223
      Dmitry Shulga authored
      of service in prepared statements).
      
      sql/sql_prepare.cc:
        At mysql_stmt_get_longdata(): instead of pushing an internal
        error handler (as done in 5.1-tree) we save, set and restore
        the statement's diagnostics area and warning info.
      feb6d223
    • Dmitry Shulga's avatar
      Fixed Bug#11764168 "56976: SEVERE DENIAL OF SERVICE IN PREPARED STATEMENTS". · 9320dca9
      Dmitry Shulga authored
      The problem was that server didn't check resulting size of prepared
      statement argument which was set using mysql_send_long_data() API.
      By calling mysql_send_long_data() several times it was possible
      to create overly big string and thus force server to allocate
      memory for it. There was no way to limit this allocation.
      
      The solution is to add check for size of result string against
      value of max_long_data_size start-up parameter. When intermediate
      string exceeds max_long_data_size value an appropriate error message
      is emitted.
      
      We can't use existing max_allowed_packet parameter for this purpose
      since its value is limited by 1GB and therefore using it as a limit
      for data set through mysql_send_long_data() API would have been an
      incompatible change. Newly introduced max_long_data_size parameter
      gets value from max_allowed_packet parameter unless its value is
      specified explicitly. This new parameter is marked as deprecated
      and will be eventually replaced by max_allowed_packet parameter.
      Value of max_long_data_size parameter can be set only at server
      startup.
      
      
      mysql-test/t/variables.test:
        Added checking for new start-up parameter max_long_data_size.
      sql/item.cc:
        Added call to my_message() when accumulated string exceeds
        max_long_data_size value. my_message() calls error handler
        that was installed in mysql_stmt_get_longdata before call
        to Item_param::set_longdata.
        
        The error handler then sets state, last_error and last_errno
        fields for current statement to values which correspond to
        error which was caught.
      sql/mysql_priv.h:
        Added max_long_data_size variable declaration.
      sql/mysqld.cc:
        Added support for start-up parameter 'max_long_data_size'.
        This parameter limits size of data which can be sent from
        client to server using mysql_send_long_data() API.
      sql/set_var.cc:
        Added variable 'max_long_data_size' into list of variables
        displayed by command 'show variables'.
      sql/sql_prepare.cc:
        Added error handler class Set_longdata_error_handler.
        This handler is used to catch any errors that can be
        generated during execution of Item_param::set_longdata().
        
        Source code snippet that makes checking for statement's state 
        during statement execution is moved from Prepared_statement::execute()
        to Prepared_statement::execute_loop() in order not to call
        set_parameters() when statement has failed during
        set_long_data() execution. If this hadn't been done
        the call to set_parameters() would have failed.
      tests/mysql_client_test.c:
        A testcase for the bug #56976 was added.
      9320dca9
    • Jon Olav Hauglid's avatar
      Bug #11765416 (former 58381) · f94e7288
      Jon Olav Hauglid authored
      FAILED DROP DATABASE CAN BREAK STATEMENT BASED REPLICATION
      
      The first phase of DROP DATABASE is to delete the tables in the database.
      If deletion of one or more of the tables fail (e.g. due to a FOREIGN KEY
      constraint), DROP DATABASE will be aborted. However, some tables could
      still have been deleted. The problem was that nothing would be written
      to the binary log in this case, so any slaves would not delete these tables.
      Therefore the master and the slaves would get out of sync.
      
      This patch fixes the problem by making sure that DROP TABLE is written
      to the binary log for the tables that were in fact deleted by the failed
      DROP DATABASE statement.
      
      Test case added to binlog.binlog_database.test.
      f94e7288
    • Bjorn Munch's avatar
  7. 14 Mar, 2011 3 commits