1. 15 Jan, 2009 7 commits
  2. 14 Jan, 2009 7 commits
    • MySQL Build Team's avatar
    • Ramil Kalimullin's avatar
      bug#33094: Error in upgrading from 5.0 to 5.1 when table contains triggers · 48c3f39e
      Ramil Kalimullin authored
      Post-fix test failure: fixed mysqlcheck.test on Windows platforms.
      
      
      mysql-test/r/mysqlcheck.result:
        fixed mysqlcheck.test on Windows platforms.
      mysql-test/t/mysqlcheck.test:
        fixed mysqlcheck.test on Windows platforms.
      48c3f39e
    • unknown's avatar
      Raise version number after cloning 5.0.76 · 9c68e0b3
      unknown authored
      9c68e0b3
    • Chad MILLER's avatar
      Merge from bugteam trunk. · 470d5320
      Chad MILLER authored
      470d5320
    • Ramil Kalimullin's avatar
      Fix for · d4b81e11
      Ramil Kalimullin authored
      bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
      triggers
      and
      #41385: Crash when attempting to repair a #mysql50# upgraded table
      with triggers.
      
      Problem:
      1. trigger code didn't assume a table name may have
      a "#mysql50#" prefix, that may lead to a failing ASSERT().
      2. "ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME" failed
      for databases with "#mysql50#" prefix if any trigger.
      3. mysqlcheck --fix-table-name didn't use UTF8 as a default
      character set that resulted in (parsing) errors for tables with
      non-latin symbols in their names and definitions of triggers.
      
      Fix:
      1. properly handle table/database names with "#mysql50#" prefix.
      2. handle --default-character-set mysqlcheck option;
      if mysqlcheck is launched with --fix-table-name or --fix-db-name
      set default character set to UTF8 if no --default-character-set
      option given.
      
      Note: if given --fix-table-name or --fix-db-name option,
      without --default-character-set mysqlcheck option
      default character set is UTF8.
      
      
      client/mysqlcheck.c:
        Fix for
        bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
        triggers
        and
        #41385: Crash when attempting to repair a #mysql50# upgraded table
        with triggers.
          - check and set default charset if --default-character-set option
            given.
          - set default charset to "utf8" if there's
            --fix-table-name or --fix-db-name and no --default-character-set.
      mysql-test/r/mysqlcheck.result:
        Fix for
        bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
        triggers
        and
        #41385: Crash when attempting to repair a #mysql50# upgraded table
        with triggers.
          - test result.
      mysql-test/t/mysqlcheck.test:
        Fix for
        bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
        triggers
        and
        #41385: Crash when attempting to repair a #mysql50# upgraded table
        with triggers.
          - test case.
      sql/mysql_priv.h:
        Fix for
        bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
        triggers
        and
        #41385: Crash when attempting to repair a #mysql50# upgraded table
        with triggers.
          - check_n_cut_mysql50_prefix() introduced.
      sql/sql_table.cc:
        Fix for
        bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
        triggers
        and
        #41385: Crash when attempting to repair a #mysql50# upgraded table
        with triggers.
          - tablename_to_filename() code split into 2 parts
          - check_n_cut_mysql50_prefix() introduced to cut #mysql50# prefixes,
            used in the trigger code as well.
      sql/sql_trigger.cc:
        Fix for
        bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
        triggers
        and
        #41385: Crash when attempting to repair a #mysql50# upgraded table
        with triggers.
          - Table_triggers_list::check_n_load() - checking triggers assume
            a table/database name given may have "#mysql50#" prefix in some cases.
          - Table_triggers_list::change_table_name_in_triggers() -
            create .TRG file in new database directory and delete it in old one,
            as they may differ in case of
            "ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME"
          - Table_triggers_list::change_table_name_in_trignames() - remove stale .TRN
            files in #mysql50#dbname directory in case of database upgrade
          - Table_triggers_list::change_table_name() - allow changing trigger's
            database in case of its upgrading
      sql/sql_trigger.h:
        Fix for
        bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
        triggers
        and
        #41385: Crash when attempting to repair a #mysql50# upgraded table
        with triggers.
          - new old_db_name parameter added in
            Table_triggers_list::change_table_name_in_trignames() and
            Table_triggers_list::change_table_name_in_triggers()
      d4b81e11
    • He Zhenxing's avatar
      Auto merge · 3bc41ea7
      He Zhenxing authored
      3bc41ea7
    • He Zhenxing's avatar
      BUG#41986 Replication slave does not pick up proper AUTO_INCREMENT value for Innodb tables · 04672c1b
      He Zhenxing authored
      The next number (AUTO_INCREMENT) field of the table for write
      rows events are not initialized, and cause some engines (innodb)
      not correctly update the tables's auto_increment value.
      
      This patch fixed this problem by honor next number fields if present.
      
      mysql-test/extra/rpl_tests/rpl_auto_increment.test:
        Add test code for BUG#41986
      mysql-test/suite/rpl/r/rpl_auto_increment.result:
        update test result file for BUG#41986
      sql/log_event.cc:
        set next_number_field before writing rows, and reset next_number_field after finished writing rows
      04672c1b
  3. 13 Jan, 2009 8 commits
    • Davi Arnaut's avatar
      Bug#36326: nested transaction and select · a9aaa09b
      Davi Arnaut authored
      The problem is that the query cache stores packets containing
      the server status of the time when the cached statement was run.
      This might lead to a wrong transaction status in the client side
      if a statement is cached during a transaction and is later served
      outside a transaction context (and vice-versa).
      
      The solution is to take into account the transaction status when
      storing in and serving from the query cache.
      
      mysql-test/r/innodb_cache.result:
        Update test case result.
      mysql-test/r/query_cache.result:
        Add test case result for Bug#36326
      mysql-test/t/query_cache.test:
        Add test case for Bug#36326
      sql/mysql_priv.h:
        Add new flags.
      sql/sql_cache.cc:
        Remember the transaction and autocommit status stored in the packet.
      tests/mysql_client_test.c:
        Add test case for Bug#36326
      a9aaa09b
    • Chad MILLER's avatar
      Merge fix for bug 38364. · 0c5c7287
      Chad MILLER authored
      0c5c7287
    • Matthias Leich's avatar
      Merge into actual tree · bafb3797
      Matthias Leich authored
      bafb3797
    • Davi Arnaut's avatar
      Auto-merge from upstream 5.1-bugteam · e719da70
      Davi Arnaut authored
      e719da70
    • Matthias Leich's avatar
      Merge of fix for bug · 025960f7
      Matthias Leich authored
         41776 type_date.test may fail if run around midnight.
      into GCA tree.
      025960f7
    • Matthias Leich's avatar
      Merge of fix for bug · 35d4d6c9
      Matthias Leich authored
         41111 events_bugs fails sporadically on pushbuild
      into GCA tree
      35d4d6c9
    • Matthias Leich's avatar
      Merge of fix for bug · eb5893ec
      Matthias Leich authored
      41932 funcs_1: is_collation_character_set_applicability path too long for tar
      into GCA tree
      eb5893ec
    • Matthias Leich's avatar
      Fix for Bug#40377 sporadic pushbuild failure in log_state: result mismatch · 191561ee
      Matthias Leich authored
      + add workaround for bug 38124
      + messages into the protocol when sessions are switched
      + replace error numbers by error names
      + reset of system variables to initial values per subtest
      + remove a file created by this test
      + minor improvements in structure and formatting
      191561ee
  4. 12 Jan, 2009 6 commits
    • Patrick Crews's avatar
      Bug#41888: Test binlog.binlog_database causing binlog_innodb to fail on Pushbuild. · 3b80d15e
      Patrick Crews authored
      Added cleanup of status variables to the end of binlog_database.
      Re-recorded .result file to account for cleanup statement.
      NOTE:  binlog.binlog_innodb also has had an FLUSH STATUS; statement added to it as well, but
      adding this cleanup as a preventative measure.
      3b80d15e
    • Chad MILLER's avatar
      Bug#38364: gen_lex_hash segmentation fault in debug build · eadcb205
      Chad MILLER authored
      Bug#36428: MY_MUTEX_INIT_FAST is used before initialization
      
      On some thread implementations, we need a fake mutex attri-
      bute as a placeholder, which we define as a global variable,
      "my_fast_mutexattr".  Well. that must be initialized before 
      used in any mutexes, and the ordering of initializations in 
      the API function  my_init()  was wrong.
      
      Now, put my_thread_global_init(), which initializes the attri-
      butes that mutexes require.
      eadcb205
    • Georgi Kodinov's avatar
      Fixed a warning in sql_profile.cc · bae9df80
      Georgi Kodinov authored
      bae9df80
    • Georgi Kodinov's avatar
      merged 41453 to 5.1-bugteam · 48a4d54e
      Georgi Kodinov authored
      48a4d54e
    • Davi Arnaut's avatar
      Post-merge fix for bug 37016: Update test case for row-based logging. · 3c60cf19
      Davi Arnaut authored
      mysql-test/r/commit_1innodb.result:
        Increase commit count for row-based logging.
      3c60cf19
    • Tatiana A. Nurnberg's avatar
      Bug#31177: Server variables can't be set to their current values · 7a3c3619
      Tatiana A. Nurnberg authored
      Bounds-checks and blocksize corrections were applied to user-input,
      but constants in the server were trusted implicitly. If these values
      did not actually meet the requirements, the user could not set change
      a variable, then set it back to the (wonky) factory default or maximum
      by explicitly specifying it (SET <var>=<value> vs SET <var>=DEFAULT).
      
      Now checks also apply to the server's presets. Wonky values and maxima
      get corrected at startup. Consequently all non-offsetted values the user
      sees are valid, and users can set the variable to that exact value if
      they so desire.
      
      mysql-test/r/read_buffer_size_basic.result:
        test sets out of bounds value; we now throw a warning for this.
        This is a side-effect: before, the maximum was higher than the
        value we set here. The value was corrected to block-size, the
        maximum was not, hence the value was smaller than the maximum
        in this particular case. Now that we align the maxima at startup,
        the value in SET is larger than the (corrected) maximum, and we
        see a warning in this particular case. "This means we're doing it right."
      mysql-test/r/read_rnd_buffer_size_basic.result:
        test sets out of bounds value; we now throw a warning for this.
        This is a side-effect: before, the maximum was higher than the
        value we set here. The value was corrected to block-size, the
        maximum was not, hence the value was smaller than the maximum
        in this particular case. Now that we align the maxima at startup,
        the value in SET is larger than the (corrected) maximum, and we
        see a warning in this particular case. "This means we're doing it right."
      mysys/my_getopt.c:
        Do bounds-checking at start-up time so we'll catch and correct
        wonky default values and upper limits.
      sql/mysqld.cc:
        If 0 is a legal value per the docs, not to mention the default, we shouldn't give 1 as
        the lower limit.
      storage/innobase/handler/ha_innodb.cc:
        We are setting upper bounds here.
        ~0L gives -1. That is NOT what we want!
      7a3c3619
  5. 09 Jan, 2009 12 commits