1. 13 Jan, 2009 3 commits
  2. 12 Jan, 2009 1 commit
    • 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
  3. 09 Jan, 2009 17 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 #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
  4. 08 Jan, 2009 6 commits
    • Davi Arnaut's avatar
      Auto-merge from upstream 5.1-bugteam · 1a6452a2
      Davi Arnaut authored
      1a6452a2
    • Horst Hunger's avatar
      4e517726
    • 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
  5. 07 Jan, 2009 7 commits
    • Mattias Jonsson's avatar
      merge · 50c10a18
      Mattias Jonsson authored
      50c10a18
    • Mattias Jonsson's avatar
      merge · f1731568
      Mattias Jonsson authored
      f1731568
    • Matthias Leich's avatar
    • Patrick Crews's avatar
      merge · af739b2c
      Patrick Crews authored
      af739b2c
    • Patrick Crews's avatar
      merge · 9b1a8728
      Patrick Crews authored
      9b1a8728
    • Vladislav Vaintroub's avatar
      fix misspelling · 4bd55050
      Vladislav Vaintroub authored
      4bd55050
    • Davi Arnaut's avatar
      Bug#41348: INSERT INTO tbl SELECT * FROM temp_tbl overwrites · 7ba37134
      Davi Arnaut authored
                 locking type of temp table
      
      The problem is that INSERT INTO .. SELECT FROM .. and CREATE
      TABLE .. SELECT FROM a temporary table could inadvertently
      overwrite the locking type of the temporary table. The lock
      type of temporary tables should be a write lock by default.
      
      The solution is to reset the lock type of temporary tables
      back to its default value after they are used in a statement.
      
      mysql-test/r/innodb_mysql.result:
        Add test case result for Bug#41348
      mysql-test/r/temp_table.result:
        Add test case result for Bug#41348
      mysql-test/t/innodb_mysql.test:
        Add test case for Bug#41348
      mysql-test/t/temp_table.test:
        Add test case for Bug#41348
      sql/sql_base.cc:
        Allow the lock type of temp tables to be overwritten now that
        the the value is being restored once the table is marked as
        free for re-use. This makes the behavior consistent with that
        of non-temporary tables and avoids confusion.
      7ba37134
  6. 05 Jan, 2009 6 commits