An error occurred fetching the project authors.
- 21 Aug, 2006 1 commit
-
-
sergefp@mysql.com authored
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
-
-
sergefp@mysql.com 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.
-
- 12 Jul, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz 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.
-
- 23 May, 2006 1 commit
-
-
gkodinov@mysql.com authored
Moved the InnoDB related tests to innodb_mysql
-
- 22 May, 2006 1 commit
-
-
gkodinov@mysql.com authored
Moved the InnoDB related test from func_group.test to innodb_mysql.test
-
- 06 May, 2006 1 commit
-
-
sergefp@mysql.com 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().
-
- 26 Apr, 2006 2 commits
-
-
aivanov@mysql.com authored
-
aivanov@mysql.com authored
Use files innodb_mysql.[test|result] instead.
-
- 20 Aug, 2003 1 commit
-
-
guilhem@mysql.com 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 !
-