1. 14 Jan, 2009 3 commits
    • Ramil Kalimullin's avatar
      Fix for · 53e42d9e
      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()
      53e42d9e
    • He Zhenxing's avatar
      Auto merge · 45140a8e
      He Zhenxing authored
      45140a8e
    • He Zhenxing's avatar
      BUG#41986 Replication slave does not pick up proper AUTO_INCREMENT value for Innodb tables · f2c122bf
      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
      f2c122bf
  2. 13 Jan, 2009 6 commits
  3. 12 Jan, 2009 5 commits
    • Patrick Crews's avatar
      Bug#41888: Test binlog.binlog_database causing binlog_innodb to fail on Pushbuild. · fed5e977
      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.
      fed5e977
    • Georgi Kodinov's avatar
      Fixed a warning in sql_profile.cc · b91bbba2
      Georgi Kodinov authored
      b91bbba2
    • Georgi Kodinov's avatar
      merged 41453 to 5.1-bugteam · e0df7f1c
      Georgi Kodinov authored
      e0df7f1c
    • Davi Arnaut's avatar
      Post-merge fix for bug 37016: Update test case for row-based logging. · d1323f43
      Davi Arnaut authored
      mysql-test/r/commit_1innodb.result:
        Increase commit count for row-based logging.
      d1323f43
    • Tatiana A. Nurnberg's avatar
      Bug#31177: Server variables can't be set to their current values · 95e0d3bd
      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!
      95e0d3bd
  4. 09 Jan, 2009 18 commits
    • Tatiana A. Nurnberg's avatar
      auto-merge · 22918578
      Tatiana A. Nurnberg authored
      22918578
    • Georgi Kodinov's avatar
      merged 5.0-bugteam -> 5.1-bugteam · e22027ae
      Georgi Kodinov authored
      e22027ae
    • Georgi Kodinov's avatar
      fixed a compile warning · 529fff05
      Georgi Kodinov authored
      529fff05
    • Georgi Kodinov's avatar
      merged 41437 to 5.1-bugteam · d09185fa
      Georgi Kodinov authored
      d09185fa
    • Tatiana A. Nurnberg's avatar
      auto-merge · 7e0ec5c4
      Tatiana A. Nurnberg authored
      7e0ec5c4
    • Georgi Kodinov's avatar
      merged 41437 to 5.0-bugteam · af0e03b2
      Georgi Kodinov authored
      af0e03b2
    • Matthias Leich's avatar
      1. Fix for Bug#41111 events_bugs fails sporadically on pushbuild · f0d1d533
      Matthias Leich authored
      2. Avoid bad effects of bug 41925 Warning 1366 Incorrect string value:
                                        ...  for column processlist.info
      3. Add poll routines which ensure that subtests meet stable scenarios.
         This does not change the sense of the subtests.
      f0d1d533
    • Tatiana A. Nurnberg's avatar
      auto-merge · d3c4a5cb
      Tatiana A. Nurnberg authored
      d3c4a5cb
    • Mattias Jonsson's avatar
      merge · fffe666f
      Mattias Jonsson authored
      fffe666f
    • Mattias Jonsson's avatar
      Bug#40972: Partition pruning can lead to crash for bad dates · efea2e68
      Mattias Jonsson authored
      post push fix, added test found a valgrind warning
      
      sql/sql_partition.cc:
        Bug#40972: Partition pruning can lead to crash for bad dates
        
        Fix for valgrind warning
      efea2e68
    • Sven Sandberg's avatar
      BUG#41924: high-level replication functions are not commented · 8576423d
      Sven Sandberg authored
      Adding comments to some of the high-level functions in replication.
      
      sql/log_event.h:
        Fixed some mistakes in comments.
      sql/repl_failsafe.cc:
        Added comment for show_slave_hosts()
      sql/slave.cc:
        Added comment for show_master_info(), handle_slave_[sql|io](), and next_event()
      sql/sql_binlog.cc:
        Added @param comment.
      sql/sql_lex.h:
        Added comment for st_lex_master_info.
      sql/sql_repl.cc:
        Added comments for functions executing a statement:
            PURGE BINARY LOGS
            START SLAVE
            STOP SLAVE
            RESET SLAVE
            CHANGE MASTER
            RESET MASTER
            SHOW BINLOG EVENTS
            SHOW MASTER STATUS
            SHOW BINARY LOGS
      8576423d
    • Georgi Kodinov's avatar
      Bug #41543: Assertion `m_status == DA_ERROR' failed in Diagnostics_area::sql_errno · 5f458562
      Georgi Kodinov authored
      No need to mask the error code returned by getting the next row to end of file when
      doing filesort.
      
      mysql-test/r/innodb_mysql_rbk.result:
        Bug #41543: test case
      mysql-test/t/innodb_mysql_rbk-master.opt:
        Bug #41543: test case
      mysql-test/t/innodb_mysql_rbk.test:
        Bug #41543: test case
      sql/filesort.cc:
        Bug #41543: No need to mask the error code returned by getting the next row to end of file when
        doing filesort.
      5f458562
    • Georgi Kodinov's avatar
      Bug #41437: Value stored in 'case' lacks charset, causes segfault · ac885d5d
      Georgi Kodinov authored
      When substituting system constant functions with a constant result
      the server was not expecting that the function may return NULL.
      Fixed by checking for NULL and returning Item_null (in the relevant
      collation) if the result of the system constant function was NULL.
      
      mysql-test/r/mysql.result:
        Bug #41437: test case
      mysql-test/t/mysql.test:
        Bug #41437: test case.
        Relies on database() returning NULL if no database is
        selected.
      sql/item_strfunc.cc:
        Bug #41437: Check for NULL result on evaluating the system
        constant function and return a constant NULL item.
      ac885d5d
    • Sven Sandberg's avatar
    • Sven Sandberg's avatar
    • Davi Arnaut's avatar
      Bug#37016: TRUNCATE TABLE removes some rows but not all · 8dbb9c88
      Davi Arnaut authored
      The special TRUNCATE TABLE (DDL) transaction wasn't being properly
      rolled back if a error occurred during row by row deletion. The
      error can be caused by a foreign key restriction imposed by InnoDB
      SE and would cause the server to erroneously issue a implicit
      commit.
      
      The solution is to rollback the transaction if a truncation via row
      by row deletion fails, otherwise commit. All effects of a TRUNCATE 
      ABLE operation are rolled back if a row by row deletion fails.
      
      mysql-test/include/commit.inc:
        Truncate always starts a transaction and commits at the end.
        The commit at the end increases the count by two, one is the
        storage engine commit and the other is the binary log.
      mysql-test/r/commit_1innodb.result:
        Update test case results.
      mysql-test/r/innodb_mysql.result:
        Update test case results.
      mysql-test/t/innodb_mysql.test:
        Add test case for Bug#37016
      sql/sql_delete.cc:
        Move truncation using row by row deletion to its own function.
        If row by row deletion fails, rollback the transaction.
        
        Remove the meddling with disabling and enabling of autocommit
        as TRUNCATE transaction is now explicitly ended (committed
        or rolled back).
      8dbb9c88
    • Sven Sandberg's avatar
      BUG#41961: Some log_event types do not skip post-header when reading · 5c92f27f
      Sven Sandberg authored
      Problem: when the server reads a log_event from file, it should read
      the post-header lengths from the format_description_log_event. Some
      event types which currently have post-header length 0 did not do this,
      and instead had a hard-coded zero length for the post-header. That
      means the current server version will not be able to read future
      versions of these events.
      Fix: make the reader functions read the post-header.
      
      
      sql/log_event.cc:
         - Made Format_description_log_event constructor initialize all
           post-header lengths explicitly, to make it easier to find them
           in the source code.
         - After this, it is no longer necessary to pass the MY_ZEROFILL
           flag to my_malloc. I removed the flag and added a sanity-check
           that will be executed only in debug-mode.
         - Made INTVAR, RAND, USER_VAR, and XID events skip post_header_len
           when reading from file.
      sql/log_event.h:
        Added explicit defines for the lengths of all event types.
      5c92f27f
    • Horst Hunger's avatar
      due to merge. · e35fc57b
      Horst Hunger authored
      e35fc57b
  5. 08 Jan, 2009 7 commits
    • Davi Arnaut's avatar
      Auto-merge from upstream 5.1-bugteam · 1a6452a2
      Davi Arnaut authored
      1a6452a2
    • Horst Hunger's avatar
      4e517726
    • Davi Arnaut's avatar
      Bug#41889: Test main.innodb_bug38231 is failing w/embedded server (server crash) · f7e77185
      Davi Arnaut authored
      The problem is that a mysql connection instance is not thread-safe
      and reentrant, meaning that it can't be used concurrently and can't
      be re-entered while it's already running. This applies for any form
      of the server (embedded or not), but this rule can be violated in a
      test case if the test sends a new command without waiting for the
      result of previous command that was sent asynchronously and this can
      lead to hangs when over a network or to crashes under embedded server
      as the server query execution path will be re-entered concurrently
      with the same connection structure.
      
      The solution is to rework the test case so that the aforementioned
      rule is obeyed.
      
      mysql-test/t/innodb_bug38231.test:
        Remove con3 as it is not necessary to reproduce the test case
        and might cause problems as there is no guarantee on which
        LOCK TABLE request will succeed first. Also, wait for statement
        result before sending a new one on the same connection.
      f7e77185
    • Mattias Jonsson's avatar
      merge · 13bb89ed
      Mattias Jonsson authored
      13bb89ed
    • Tatiana A. Nurnberg's avatar
      Bug#41470: DATE_FORMAT() crashes the complete server with a valid date · c42892d6
      Tatiana A. Nurnberg authored
      Passing dubious "year zero" in non-zero date (not "0000-00-00") could
      lead to negative value for year internally, while variable was unsigned.
      This led to Really Bad Things further down the line.
      
      Now doing calculations with signed type for year internally.
      
      mysql-test/r/date_formats.result:
        show that very early dates no longer break DATE_FORMAT(..., '%W')
      mysql-test/t/date_formats.test:
        show that very early dates no longer break DATE_FORMAT(..., '%W')
      sql-common/my_time.c:
        Allow negative years numbers internally while keeping the interface.
        otherwise if somebody passes year zero for whatever reason, we'll
        get an integer wrap-around that can lead to Really Bad Things further
        down the line. Note that amusingly, calcday_nr() already had signed
        output and calc_weekday() already had signed input, anyway.
      c42892d6
    • Timothy Smith's avatar
      Auto-merge from upstream 5.1-bugteam · a58bc1be
      Timothy Smith authored
      a58bc1be
    • Timothy Smith's avatar
      Fix a few problems after latest bunch of InnoDB snapshot changes: · 88cd7a98
      Timothy Smith authored
      The binlog_innodb test was sensitive to what tests ran before it.  Now run
      FLUSH STATUS before performing operations that need to be checked.
      
      sys_var_thd_ulong::update() was improperly casting an option value from
      ulonglong to ulong before comparing it to the max allowed value.  On systems
      where ulong and ulonglong are of different size, this caused values greater
      than ULONG_MAX to wrap around (not be truncated to ULONG_MAX, which appears to
      have been the intention of the original coder), and caused some checks to work
      incorrectly.  This wasn't generally visible to the user, because later checks
      would prevent the wrapped-around value from being used.  But it caused warning
      messages to differ between 32- and 64-bit platforms.  Fix is to just remove the
      cast.  Also added a DBUG_ASSERT to ensure that the value really is capped
      properly before finally stuffing it into the ulong.
      88cd7a98
  6. 07 Jan, 2009 1 commit