An error occurred fetching the project authors.
- 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
-