An error occurred fetching the project authors.
- 19 Apr, 2007 1 commit
-
-
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
-
- 11 Feb, 2007 1 commit
-
-
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.
-
- 19 Dec, 2006 1 commit
-
-
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.
-
- 30 Oct, 2006 1 commit
-
-
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
-
- 25 Oct, 2006 2 commits
-
-
unknown authored
-
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).
-
- 11 Oct, 2006 1 commit
-
-
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.
-
- 09 Oct, 2006 1 commit
-
-
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.
-
- 28 Sep, 2006 1 commit
-
-
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.
-
- 05 Sep, 2006 1 commit
-
-
unknown authored
-
- 21 Aug, 2006 1 commit
-
-
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
-
- 15 Aug, 2006 1 commit
-
-
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
-
- 12 Jul, 2006 1 commit
-
-
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
-
- 23 May, 2006 1 commit
-
-
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
-
- 22 May, 2006 1 commit
-
-
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
-
- 06 May, 2006 1 commit
-
-
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.
-
- 26 Apr, 2006 2 commits
-
-
unknown authored
mysql-test/r/innodb_mysql.result: Fix result.
-
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.
-
- 20 Aug, 2003 1 commit
-
-
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
-