1. 09 Jan, 2009 5 commits
    • Sven Sandberg's avatar
    • Sven Sandberg's avatar
    • Davi Arnaut's avatar
      Bug#37016: TRUNCATE TABLE removes some rows but not all · 87f368eb
      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).
      87f368eb
    • Sven Sandberg's avatar
      BUG#41961: Some log_event types do not skip post-header when reading · 2d3a1a63
      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.
      2d3a1a63
    • Horst Hunger's avatar
      due to merge. · 38704f69
      Horst Hunger authored
      38704f69
  2. 08 Jan, 2009 5 commits
    • Davi Arnaut's avatar
      Auto-merge from upstream 5.1-bugteam · 46a6b52b
      Davi Arnaut authored
      46a6b52b
    • Horst Hunger's avatar
      6f63a282
    • Mattias Jonsson's avatar
      merge · b8d2461e
      Mattias Jonsson authored
      b8d2461e
    • Timothy Smith's avatar
      Auto-merge from upstream 5.1-bugteam · 975b8085
      Timothy Smith authored
      975b8085
    • Timothy Smith's avatar
      Fix a few problems after latest bunch of InnoDB snapshot changes: · 53464956
      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.
      53464956
  3. 07 Jan, 2009 5 commits
    • Mattias Jonsson's avatar
      merge · 682c4d07
      Mattias Jonsson authored
      682c4d07
    • Mattias Jonsson's avatar
      merge · 866d10a4
      Mattias Jonsson authored
      866d10a4
    • Patrick Crews's avatar
      merge · 4b836727
      Patrick Crews authored
      4b836727
    • Vladislav Vaintroub's avatar
      fix misspelling · 4f76ed9b
      Vladislav Vaintroub authored
      4f76ed9b
    • Davi Arnaut's avatar
      Bug#41348: INSERT INTO tbl SELECT * FROM temp_tbl overwrites · 1b333f64
      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.
      1b333f64
  4. 05 Jan, 2009 6 commits
  5. 31 Dec, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #41363: crash of mysqld on windows with aggregate in case · 299b7a97
      Gleb Shchepa authored
      Execution of queries containing the CASE function of
      aggregate function like in "SELECT ... CASE ARGV(...) WHEN ..."
      crashed the server.
      
      
      The CASE function caches pointers to concrete comparison
      functions for an each pair of types of CASE-WHERE clause
      parameters, i.e. for the "CASE INT_RESULT WHERE REAL_RESULT
      THEN ... WHERE DECIMAL_RESULT ... END" function call it
      caches comparisons for INT_RESULT with REAL_RESULT and
      for INT_RESULT with DECIMAL_RESULT. Usually a result
      type is known after a call to the fix_fields function,
      however, the setup_copy_fields function call may
      wrap aggregate items with Item_copy_string that has
      STRING_RESULT result type, so setup_copy_fields may
      change argument result types of the CASE function after
      call to Item_func_case::fix_fields/fix_length_and_dec.
      Then the Item_func_case::find_item function tries to
      use comparison function for unexpected pair of the
      STRING_RESULT and some other type - that caused
      an assertion failure of server crash.
      
      The Item_func_case::fix_length_and_dec function has
      been modified to take into account possible STRING_RESULT
      result type in the presence of aggregate arguments of
      the CASE function.
      
      
      mysql-test/r/func_in.result:
        Added test case for bug #41363.
      mysql-test/t/func_in.test:
        Added test case for bug #41363.
      sql/item_cmpfunc.cc:
        Bug #41363: crash of mysqld on windows with aggregate in case
        
        The Item_func_case::fix_length_and_dec function has
        been modified to take into account possible STRING_RESULT
        result type in the presence of aggregate arguments of
        the CASE function.
      299b7a97
  6. 30 Dec, 2008 5 commits
  7. 29 Dec, 2008 4 commits
    • Sven Sandberg's avatar
      BUG#40482: server/mysqlbinlog crashes when reading invalid Incident_log_event · dc3ad27a
      Sven Sandberg authored
      Problem: When an Incident_log_event contains a bad incident number on disk,
      the server crashes with an assertion.
      Fix: Don't validate input with assertions. Use errors.
      
      mysql-test/include/cleanup_fake_relay_log.inc:
        Added auxiliary file to restore things that setup_fake_relay_log.inc did.
      mysql-test/include/setup_fake_relay_log.inc:
        Added auxiliary file to setup replication from an existing relay log.
      mysql-test/std_data/bug40482-bin.000001:
        Binlog file for rpl.rpl_binlog_corruption
      mysql-test/suite/rpl/t/rpl_binlog_corruption.test:
        New test file.
      sql/log_event.cc:
        Check that the incident number is correct at the time the event is constructed.
        Do not assert it at the time it is printed.
      sql/log_event.h:
        Incident_log_event::is_valid() should verify that the incident number is valid.
      sql/rpl_constants.h:
        Incident numbers should be hard-coded, since they may appear in files.
      dc3ad27a
    • Sergey Glukhov's avatar
      Bug#41441 repair csv table crashes debug server · f2d3fe4c
      Sergey Glukhov authored
      The problem: data file can not be deleted on win because
      there is another opened instance of this file.
      Data file might be opened twice, on table opening stage and
      during write_row execution. We need to close both instances
      to satisfy Win.
      
      
      mysql-test/r/csv.result:
        test result
      mysql-test/t/csv.test:
        test case
      storage/csv/ha_tina.cc:
        The problem: data file can not be deleted on win because
        there is another opened instance of this file.
        Data file might be opened twice, on table opening stage and
        during write_row execution. We need to close both instances
        to satisfy Win.
      f2d3fe4c
    • Sergey Glukhov's avatar
      5.0-bugteam->5.1-bugteam merge · 7d2256e4
      Sergey Glukhov authored
      7d2256e4
    • Sergey Glukhov's avatar
      Bug#41131 "Questions" fails to increment - ignores statements instead stored procs(5.0 ver) · 397a36c7
      Sergey Glukhov authored
      Added global status variable 'Queries' which represents
      total amount of queries executed by server including
      statements executed by SPs.
      note: It's old behaviour of 'Questions' variable.
      
      
      mysql-test/r/status.result:
        test result
      mysql-test/t/status.test:
        test case
      sql/mysqld.cc:
        Added global status variable 'Queries' which represents
        total amount of queries executed by server including
        statements executed by SPs.
        note: It's old behaviour of 'Questions' variable.
      sql/sql_show.cc:
        Added global status variable 'Queries' which represents
        total amount of queries executed by server including
        statements executed by SPs.
        note: It's old behaviour of 'Questions' variable.
      sql/structs.h:
        Added global status variable 'Queries' which represents
        total amount of queries executed by server including
        statements executed by SPs.
        note: It's old behaviour of 'Questions' variable.
      397a36c7
  8. 28 Dec, 2008 6 commits
  9. 24 Dec, 2008 3 commits
    • Sergey Glukhov's avatar
      5.0-bugteam->5.1-bugteam merge · 53453777
      Sergey Glukhov authored
      53453777
    • Sergey Glukhov's avatar
      Bug#40953 SELECT query throws "ERROR 1062 (23000): Duplicate entry..." error · 4c689750
      Sergey Glukhov authored
      Table could be marked dependent because it is
      either 1) an inner table of an outer join, or 2) it is a part of
      STRAIGHT_JOIN. In case of STRAIGHT_JOIN table->maybe_null should not
      be assigned. The fix is to set st_table::maybe_null to 'true' only
      for those tables which are used in outer join.
      
      
      
      mysql-test/r/select.result:
        test result
      mysql-test/t/select.test:
        test case
      sql/sql_select.cc:
        Table could be marked dependent because it is
        either 1) an inner table of an outer join, or 2) it is a part of
        STRAIGHT_JOIN. In case of STRAIGHT_JOIN table->maybe_null should not
        be assigned. The fix is to set st_table::maybe_null to 'true' only
        for those tables which are used in outer join.
      sql/sql_select.h:
        added comment
      4c689750
    • Sergey Glukhov's avatar
      5.0-bugteam->5.1-bugteam merge · 2a71d354
      Sergey Glukhov authored
      2a71d354