An error occurred fetching the project authors.
  1. 19 Apr, 2007 1 commit
    • unknown's avatar
      innodb_mysql.test, innodb_mysql.result: · f4d6b5de
      unknown authored
        Add test case for Bug #27210: INNODB ON DUPLICATE KEY UPDATE
      
      
      mysql-test/r/innodb_mysql.result:
        Add test case for Bug #27210: INNODB ON DUPLICATE KEY UPDATE
      mysql-test/t/innodb_mysql.test:
        Add test case for Bug #27210: INNODB ON DUPLICATE KEY UPDATE
      f4d6b5de
  2. 11 Feb, 2007 1 commit
    • unknown's avatar
      Fixed bug #26159. · 3e4f834d
      unknown authored
      A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset
      caused a crash when a query with DISTINCT was executed by a loose scan
      for an InnoDB table that had been emptied. 
      
      
      mysql-test/r/innodb_mysql.result:
        Added a test case for bug #26159.
      mysql-test/t/innodb_mysql.test:
        Added a test case for bug #26159.
      sql/opt_range.cc:
        Fixed bug #26159.
        A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset
        caused a crash when a query with DISTINCT was executed by a loose scan
        for an InnoDB table that had been emptied. 
        For an empty table quick_prefix_select->reset() was not called at all
        and thus some important initialization steps were missing.
      3e4f834d
  3. 19 Dec, 2006 1 commit
    • unknown's avatar
      Added innodb_rollback_on_timeout option to restore the 4.1 · 47b0a0b0
      unknown authored
      InnoDB timeout behavior (Bug #24200)
      
      
      mysql-test/t/innodb_mysql-master.opt:
        Set --innodb-lock-wait-timeout=2, since test for bug #24200 times out.
        
        This *could* cause random test failures if some long-running transaction concurrency is being tested.  However, such a test really should go in innodb-big or some other test file.
      47b0a0b0
  4. 30 Oct, 2006 1 commit
    • unknown's avatar
      Improve comments around FLUSH STATUS · e948c64f
      unknown authored
      It's not possible to flush the global status variables in 5.0
      Update test case so it works by recording the value of handle_rollback
      before and compare it to the value after
      
      
      mysql-test/r/innodb_mysql.result:
        Update result file
      mysql-test/t/innodb_mysql.test:
        It's not possible to reset the global status variables in 5.0 so intead its value
        is recorded and compared to the after value.
        It should not have changed.
      sql/mysqld.cc:
        Improve comments
      sql/set_var.cc:
        Improve comments
      sql/sql_class.cc:
        Improve comments
      sql/sql_class.h:
        Improve comments
      e948c64f
  5. 25 Oct, 2006 2 commits
    • unknown's avatar
      Fix after manual merge. · 6137ef86
      unknown authored
      6137ef86
    • unknown's avatar
      BUG#18819: DELETE IGNORE hangs on foreign key parent delete · e3d49f0c
      unknown authored
      If the error happens during DELETE IGNORE, nothing could be send to the
      client, thus leaving it frozen expecting the reply.
      
      The problem was that if some error occurred, it wouldn't be reported to
      the client because of IGNORE, but neither success would be reported.
      
      MySQL 4.1 would not freeze the client, but will report
      
        ERROR 1105 (HY000): Unknown error
      
      instead, which is also a bug.
      
      The solution is to report success if we are in DELETE IGNORE and some
      non-fatal error has happened.
      
      
      mysql-test/r/innodb_mysql.result:
        Add result for bug#18819: DELETE IGNORE hangs on foreign key parent
        delete.
      mysql-test/t/innodb_mysql.test:
        Add test case for bug#18819: DELETE IGNORE hangs on foreign key parent
        delete.
      sql/sql_delete.cc:
        Report success if we have got an error, but we are in DELETE IGNORE, and
        the error is not fatal (if it is, it would be reported to the client).
      e3d49f0c
  6. 11 Oct, 2006 1 commit
    • unknown's avatar
      Fix for bug #22728 "Handler_rollback value is growing". · ca126a2b
      unknown authored
      The bug is present only in 4.1, will be null-merged to 5.0
      
      For InnoDB, check value of thd->transaction.all.innodb_active_trans instead of thd->transaction.stmt.innobase_tid to see if we really need to rollback.
      
      
      mysql-test/r/innodb_mysql.result:
        Added testcase for bug #22728 "Handler_rollback value is growing"
      mysql-test/t/innodb_mysql.test:
        Added testcase for bug #22728 "Handler_rollback value is growing"
      sql/handler.cc:
        For InnoDB, check value of thd->transaction.all.innodb_active_trans instead of thd->transaction.stmt.innobase_tid to see if we really need to rollback.
      ca126a2b
  7. 09 Oct, 2006 1 commit
    • unknown's avatar
      Bug #22781: SQL_BIG_RESULT fails to influence sort plan · 45cad70f
      unknown authored
       Currently SQL_BIG_RESULT is checked only at compile time.
       However, additional optimizations may take place after
       this check that change the sort method from 'filesort'
       to sorting via index. As a result the actual plan
       executed is not the one specified by the SQL_BIG_RESULT
       hint. Similarly, there is no such test when executing
       EXPLAIN, resulting in incorrect output.
       The patch corrects the problem by testing for
       SQL_BIG_RESULT both during the explain and execution
       phases.
      
      
      mysql-test/r/bdb.result:
        Bug #22781: SQL_BIG_RESULT fails to influence sort plan
         - updated sql_big_result testcase
      mysql-test/r/group_by.result:
        Bug #22781: SQL_BIG_RESULT fails to influence sort plan
         - test case with MyISAM
      mysql-test/r/innodb.result:
        Bug #22781: SQL_BIG_RESULT fails to influence sort plan
         - updated sql_big_result testcase
      mysql-test/r/innodb_mysql.result:
        Bug #22781: SQL_BIG_RESULT fails to influence sort plan
         - test case with InnoDB
      mysql-test/r/myisam.result:
        Bug #22781: SQL_BIG_RESULT fails to influence sort plan
         - updated sql_big_result testcase
      mysql-test/t/group_by.test:
        Bug #22781: SQL_BIG_RESULT fails to influence sort plan
         - test case with MyISAM
      mysql-test/t/innodb_mysql.test:
        Bug #22781: SQL_BIG_RESULT fails to influence sort plan
         - test case with InnoDB
      sql/sql_select.cc:
        Bug #22781: SQL_BIG_RESULT fails to influence sort plan
         - When SQL_BIG_RESULT is specified, disable the optimization performed
        at execution/explain time that decides to use an index instead
        of filesort.
      45cad70f
  8. 28 Sep, 2006 1 commit
    • unknown's avatar
      Bug#22436 Four tests require "innodb" to be configured, fail in "classic" build · d8d57c77
      unknown authored
       - Disable warnings when creating the "innodb" tables if it works anyway.
       - Move test that are really innodb dependent to innodb_mysql 
      
      
      mysql-test/r/create.result:
        Move the innodb dependent test to innodb_mysql.test
      mysql-test/r/innodb_mysql.result:
        Move the innodb dependent test to innodb_mysql.test
      mysql-test/t/create.test:
        Move the innodb dependent test to innodb_mysql.test
      mysql-test/t/innodb_mysql.test:
        Move the innodb dependent test to innodb_mysql.test
      mysql-test/t/lock_multi.test:
        Disable warnings while creating the innodb table. If innodb is not available, the table will be created with default engine and thus create a warning. Regardless of this, test output should be the same.
      mysql-test/t/sp.test:
        Disable warnings while creating the innodb table. If innodb is not available, the table will be created with default engine and thus create a warning. Regardless of this, test output should be the same.
      mysql-test/t/view.test:
        Disable warnings while creating the innodb table. If innodb is not available, the table will be created with default engine and thus create a warning. Regardless of this, test output should be the same.
      d8d57c77
  9. 05 Sep, 2006 1 commit
  10. 21 Aug, 2006 1 commit
    • unknown's avatar
      Fix by Georgi Kodinov: · d2fa8e3a
      unknown authored
      Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
       - moved an InnoDB dependent test to the appropriate file
      
      
      mysql-test/r/innodb_mysql.result:
        Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
         - moved an InnoDB dependent test to the appropriate file
      mysql-test/r/join_outer.result:
        Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
         - moved an InnoDB dependent test to the appropriate file
      mysql-test/t/innodb_mysql.test:
        Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
         - moved an InnoDB dependent test to the appropriate file
      mysql-test/t/join_outer.test:
        Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0
         - moved an InnoDB dependent test to the appropriate file
      d2fa8e3a
  11. 15 Aug, 2006 1 commit
    • unknown's avatar
      BUG#21077: Possible crash caused by invalid sequence of handler::* calls: ... · 9907e970
      unknown authored
      BUG#21077: Possible crash caused by invalid sequence of handler::* calls:                                                
      The crash was caused by invalid sequence of handler::** calls:                                                           
        ha_smth->index_init();                                                                                                 
        ha_smth->index_next_same(); (2)                                                                                        
      (2) is an invalid call as it was not preceeded by any 'scan setup' call
      like index_first() or index_read(). The cause was that QUICK_SELECT::reset()
      didn't "fully reset" the quick select- current QUICK_RANGE wasn't forgotten,
      and quick select might attempt to continue reading the range, which would
      result in the above mentioned invalid sequence of handler calls.
      
      5.x versions are not affected by the bug - they already have the missing
      "range=NULL" clause.                                                    
                                                             
      
      
      mysql-test/r/innodb_mysql.result:
        Testcase for BUG#21077
      mysql-test/t/innodb_mysql.test:
        Testcase for BUG#21077
      sql/opt_range.h:
        BUG#21077: Possible crash caused by invalid sequence of handler::* calls:                                              
         - Make QUICK_SELECT::reset() really reset the quick select
      9907e970
  12. 12 Jul, 2006 1 commit
    • unknown's avatar
      Bug #17212 results not sorted correctly by ORDER BY when using index · 41445430
      unknown authored
        * don't use join cache when the incoming data set is already ordered
          for ORDER BY
          This choice must be made because join cache will effectively
          reverse the join order and the results will be sorted by the index
          of the table that uses join cache.
      
      
      mysql-test/r/innodb_mysql.result:
        Bug #17212 results not sorted correctly by ORDER BY when using index
          * Test suite for the bug
      mysql-test/t/innodb_mysql.test:
        Bug #17212 results not sorted correctly by ORDER BY when using index
          * Test suite for the bug
      sql/sql_select.cc:
        Bug #17212 results not sorted correctly by ORDER BY when using index
          * don't use join cache when the incoming data set is already sorted
      41445430
  13. 23 May, 2006 1 commit
    • unknown's avatar
      Bug #18742: Test 'group_min_max' fails if "classic" configuration in 5.0 · f112e407
      unknown authored
      Moved the InnoDB related tests to innodb_mysql
      
      
      mysql-test/r/group_min_max.result:
        Moved innodb related tests out of group_min_max
      mysql-test/r/innodb_mysql.result:
        Moved innodb related tests out of group_min_max
      mysql-test/t/group_min_max.test:
        Moved innodb related tests out of group_min_max
      mysql-test/t/innodb_mysql.test:
        Moved innodb related tests out of group_min_max
      f112e407
  14. 22 May, 2006 1 commit
    • unknown's avatar
      Bug#18745: Test case 'func_group' fails if "classic" 5.0 configuration · af3b08c5
      unknown authored
      Moved the InnoDB related test from func_group.test to innodb_mysql.test
      
      
      mysql-test/r/func_group.result:
        Moved a test to innodb_mysql
      mysql-test/r/innodb_mysql.result:
        moved a test to innodb_mysql
      mysql-test/t/func_group.test:
        Moved a test to innodb_mysql
      mysql-test/t/innodb_mysql.test:
        Moved a test to innodb_mysql
      af3b08c5
  15. 06 May, 2006 1 commit
    • unknown's avatar
      BUG#16798: Inapplicable ref_or_null query plan and bad query result on random occasions · c1314472
      unknown authored
      The bug was as follows: When merge_key_fields() encounters "t.key=X OR t.key=Y" it will 
      try to join them into ref_or_null access via "t.key=X OR NULL". In order to make this 
      inference it checks if Y<=>NULL, ignoring the fact that value of Y may be not yet known.
      
      The fix is that the check if Y<=>NULL is made only if value of Y is known (i.e. it is a
      constant).
      TODO: When merging to 5.0, replace used_tables() with const_item() everywhere in merge_key_fields().
      
      
      mysql-test/r/innodb_mysql.result:
        Testcase for BUG16798
      mysql-test/t/innodb_mysql.test:
        Testcase for BUG16798
      sql/sql_select.cc:
        BUG#16798: Inapplicable ref_or_null query plan and bad query result on random occasions 
        In merge_key_fields() don't call val->is_null() if the value of val is not known.
      c1314472
  16. 26 Apr, 2006 2 commits
    • unknown's avatar
      Make innodb_mysql produce a non-empty output. · c2e6c898
      unknown authored
      mysql-test/r/innodb_mysql.result:
        Fix result.
      c2e6c898
    • unknown's avatar
      Files innodb.[test|result] are to be used by Innobase only. · a4c62dbb
      unknown authored
       Use files innodb_mysql.[test|result] instead.
      
      
      mysql-test/t/innodb.test:
        This file is to be used by Innobase only.
      mysql-test/r/innodb_mysql.result:
        New BitKeeper file ``mysql-test/r/innodb_mysql.result''
         Use this file instead of innodb.result.
      mysql-test/t/innodb_mysql.test:
        New BitKeeper file ``mysql-test/t/innodb_mysql.test''
         Use this file instead of innodb.test.
      a4c62dbb
  17. 20 Aug, 2003 1 commit
    • unknown's avatar
      Result updates after Dmitri's and my changes to logging with --log-slave-updates. · eb1fb900
      unknown authored
      Since my changes, rpl_log.test, whose result file depends on file_id, became
      non-repeatable, i.e. file_id on slave in SHOW BINLOG EVENTS
      changed depending on the order of tests (sometimes 1, sometimes 5).
      Which is logical: as now the slave does not copy Create_file and Exec_load from
      the relay log (i.e from the master's binlog) to the slave's binlog, but
      instead lets mysql_load() do the logging, the file_id is now the one whic
      was used on the slave. Before it was the one which was used on the master,
      and by chance the master was always restarted for this test because there's
      a -master.opt file, so file_id on the master is always 1. But now file_id is
      from the slave so we need to restart the slave. That's why I add an (empty)
      -slave.opt file. I could have used 'server_stop/start slave', but this
      would have required the manager, so most of the time mysql-test-run silently
      skip the test which makes it useless. And I want this test to be run !
      
      
      mysql-test/r/rpl_loaddata.result:
        Orig_log_pos is like Pos since Dmitri's good change for BUG#1086
      mysql-test/r/rpl_log.result:
        Orig_log_pos is like Pos now, because Exec_load events are not directly copied
        by the slave from the relay log to the slave's binary log (these events
        are written by mysql_load() now).
      mysql-test/t/rpl_log.test:
        A comment
      eb1fb900