1. 06 Feb, 2012 3 commits
    • Georgi Kodinov's avatar
      merge mysql-5.5->mysql-5.5-security · 91c1c930
      Georgi Kodinov authored
      91c1c930
    • Vasil Dimov's avatar
      Merge mysql-5.1 -> mysql-5.5 · 56e3f68c
      Vasil Dimov authored
      The actual Bug#11754376 does not exist in MySQL 5.5 because at startup
      we drop entries for temporary tables from InnoDB dictionary cache (only
      if ROW_FORMAT is not REDUNDANT). But nevertheless the bug in
      normalize_table_name_low() is present so we fix it.
      56e3f68c
    • Vasil Dimov's avatar
      Fix Bug#11754376 45976: INNODB LOST FILES FOR TEMPORARY TABLES ON · 1c4fd3bb
      Vasil Dimov authored
      GRACEFUL SHUTDOWN
      
      During startup mysql picks up .frm files from the tmpdir directory and
      tries to drop those tables in the storage engine.
      
      The problem is that when tmpdir ends in / then ha_innobase::delete_table()
      is passed a string like "/var/tmp//#sql123", then it wrongly normalizes it
      to "/#sql123" and calls row_drop_table_for_mysql() which of course fails
      to delete the table entry from the InnoDB dictionary cache.
      ha_innobase::delete_table() returns an error but nevertheless mysql wipes
      away the .frm file and the entry in the InnoDB dictionary cache remains
      orphaned with no easy way to remove it.
      
      The "no easy" way to remove it is to create a similar temporary table again,
      copy its .frm file to tmpdir under "#sql123.frm" and restart mysqld with
      tmpdir=/var/tmp (no trailing slash) - this way mysql will pick the .frm file
      after restart and will try to issue drop table for "/var/tmp/#sql123"
      (notice do double slash), ha_innobase::delete_table() will normalize it to
      "tmp/#sql123" and row_drop_table_for_mysql() will successfully remove the
      table entry from the dictionary cache.
      
      The solution is to fix normalize_table_name_low() to normalize things like
      "/var/tmp//table" correctly to "tmp/table".
      
      This patch also adds a test function which invokes
      normalize_table_name_low() with various inputs to make sure it works
      correctly and a mtr test that calls this test function.
      
      Reviewed by:	Marko (http://bur03.no.oracle.com/rb/r/929/)
      1c4fd3bb
  2. 05 Feb, 2012 1 commit
  3. 03 Feb, 2012 4 commits
  4. 02 Feb, 2012 12 commits
  5. 01 Feb, 2012 1 commit
  6. 31 Jan, 2012 11 commits
  7. 30 Jan, 2012 7 commits
    • Ramil Kalimullin's avatar
      Fix for BUG#13596377: MYSQL CRASHES ON STARTUP ON FREEBSD IN PB2 · 882ef63e
      Ramil Kalimullin authored
      Fix for #36428/#38364 backported into 5.0.
      882ef63e
    • unknown's avatar
      starting 5.5.21 build · 4f8bb56c
      unknown authored
      4f8bb56c
    • unknown's avatar
      Merge with main for BUG#12969301 · 7009bf41
      unknown authored
      7009bf41
    • Inaam Rana's avatar
      Bug#11836233 MISLEADING SUGGESTION REGARDING LINUX NATIVE AIO IN INNODB · 40bab62a
      Inaam Rana authored
      ERROR LOG
      
      Fixed error meesage
      40bab62a
    • Gopal Shankar's avatar
      Merged from mysql-5.1-security · 225f0cd5
      Gopal Shankar authored
      225f0cd5
    • Tor Didriksen's avatar
      Bug#13604121 - LIBMYSQLCIENT.SO MISSING SOME FUNCTIONS PRESENT IN LIBMYSQLCLIENT.A · 2a5d2338
      Tor Didriksen authored
      +get_tty_password  this is the only external symbol in get_password.c,
                         which is explicitly listed in CLIENT_SOURCES
      +handle_options    this is in mysys/my_getopt.c
                         adding this sysmbol pulls in the other externals:
      T getopt_compare_strings
      T getopt_double_limit_value
      T getopt_ll_limit_value
      T getopt_ull_limit_value
      T handle_options
      T my_cleanup_options
      T my_getopt_register_get_addr
      T my_print_help
      T my_print_variables
      2a5d2338
    • Gopal Shankar's avatar
      Bug#13105873 :Valgrind Warning: CRASH IN FOREIGN · 7f0f18cd
      Gopal Shankar authored
            KEY HANDLING ON SUBSEQUENT CREATE TABLE IF NOT EXISTS
            
            PROBLEM:
            --------
            Consider a SP routine which does CREATE TABLE
            with REFERENCES clause. The first call to this routine
            invokes parser and the parsed items are cached, so as 
            to avoid parsing for the second execution of the routine.
            
            It is obsevered that valgrind reports a warning
            upon read of thd->lex->alter_info->key_list->Foreign_key object,
            which seem to be pointing to a invalid memory address
            during second time execution of the routine. Accessing this object
            theoretically could cause a crash.
            
            ANALYSIS:
            ---------
            The problem stems from the fact that for some reason
            elements of ref_columns list in thd->lex->alter_info->
            key_list->Foreign_key object are changed to point to
            objects allocated on runtime memory root.
            
            During the first execution of routine we create
            a copy of thd->lex->alter_info object.
            As part of this process we create a clones of objects in
            Alter_info::key_list and of Foreign_key object in particular.
            Then Foreign_key object is cloned for some reason we
            perform shallow copies of both Foreign_key::ref_columns
            and Foreign_key::columns list. So new instance of 
            Foreign_key object starts to SHARE contents of ref_columns
            and columns list with the original instance.
            After that as part of cloning process we call
            list_copy_and_replace_each_value() for elements of
            ref_columns list. As result ref_columns lists in both
            original and cloned Foreign_key object start to contain
            pointers to Key_part_spec objects allocated on runtime
            memory root because of shallow copy.
            
            So when we start copying of thd->lex->alter_info object
            during the second execution of stored routine we indeed
            encounter pointer to the Key_part_spec object allocated
            on runtime mem-root which was cleared during at the end
            of previous execution. This is done in sp_head::execute(), 
            by a call to free_root(&execute_mem_root,MYF(0));
            As result we get valgrind warnings about accessing 
            unreferenced memory.
            
            FIX:
            ----
            The safest solution to this problem is to 
            fix Foreign_key(Foreign_key, MEM_ROOT) constructor to do
            a deep copy of columns lists, similar to Key(Key, MEM_ROOT) 
            constructor.
      7f0f18cd
  8. 27 Jan, 2012 1 commit