- 28 Nov, 2008 1 commit
-
-
Matthias Leich authored
- disable the test suffering from Bug#41098 Query Cache returns wrong result with concurrent insert - additional improvements Details: - Move the test for the historic bug Bug 28249 Query Cache returns wrong result with concurrent insert / certain lock into its own testscript query_cache_28249.test. - query_cache.test: - replace error numbers with error names - remove trailing spaces, replace tabs with spaces - reset of @@global.log_bin_trust_function_creators to its original value at the end of the test - query_cache_28249.test: - replace sleep 5 with poll routine - avoid random differences caused by concurrent_inserts effects - improved comments and formatting
-
- 26 Nov, 2008 6 commits
-
-
Patrick Crews authored
-
Patrick Crews authored
-
Ingo Struewing authored
-
Matthias Leich authored
(no conflicts)
-
Ingo Struewing authored
-
Horst Hunger authored
-
- 25 Nov, 2008 12 commits
-
-
Matthias Leich authored
-
Matthias Leich authored
-
Ingo Struewing authored
symlink.test failed when run in an environment that has mysql-test/var symlinked to elsewhere, e.g. a memory file system. This is the case when running mysql-test-run --mem. In this case the server does not detect that the directory specified with a DATA/INDEX DIRECTORY clause is within its data home directory. This problem was reported as Bug#39277 (Creation of table with data and/or index files in data home directory succeeds). It was decided that it will not be fixed in 5.1. Hence, the current behavior is accepted for 5.1. It will be fixed in 6.0 though. Fixed the test case so that it works in both environments. 1. When no symbolic link is involved, the server notices that the data/index directory is in its data hone directory and rejects the CREATE/ALTER TABLE statement. 2. When the data home directory is symlinked, it does not notice the problem and executes the statement sucessfully.
-
Matthias Leich authored
-
Matthias Leich authored
-
Matthias Leich authored
-
Matthias Leich authored
-
Ingo Struewing authored
-
Ramil Kalimullin authored
-
Ingo Struewing authored
-
Ingo Struewing authored
-
Ramil Kalimullin authored
Problem: in 5.0 'check table for upgrade' doesn't detect incompatible collation changes made in 5.0.48. Fix: backport #39585 fix to 5.0
-
- 24 Nov, 2008 7 commits
-
-
Mattias Jonsson authored
-
Patrick Crews authored
-
Patrick Crews authored
Altering how MTR checks global variable status to exclude timestamp Changed SQL statements to update style.
-
Mattias Jonsson authored
Problem was usage of read_range_first with an empty key. Solution was to not to give a key if it was empty.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
ONLY_FULL_GROUP_BY The check for non-aggregated columns in queries with aggregate function, but without GROUP BY was treating all the parts of the query as if they are in the SELECT list. Fixed by ignoring the non-aggregated fields in the WHERE clause.
-
- 22 Nov, 2008 2 commits
-
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
- 21 Nov, 2008 12 commits
-
-
Ingo Struewing authored
Several system variables did not behave like system variables should do. When trying to SET them or use them in SELECT, they were reported as "unknown system variable". But they appeared in SHOW VARIABLES. This has been fixed by removing the "fixed_vars" array of variables and integrating the variables into the normal system variables chain. All of these variables do now behave as read-only global-only variables. Trying to SET them tells they are read-only, trying to SELECT the session value tells they are global only. Selecting the global value works. It delivers the same value as SHOW VARIABLES.
-
Matthias Leich authored
-
Matthias Leich authored
- restore original state of event_scheduler at the end of the test - minor fixes around comments, formatting
-
Horst Hunger authored
-
Horst Hunger authored
-
Alexey Botchkov authored
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
the problem is the same as reported in bug#20835, so the fix is backport of bug#20835 patch.
-
Vladislav Vaintroub authored
-
Ramil Kalimullin authored
returns truncated results Problem: performig conversion from {INT, DECIMAL, REAL} to CHAR we incorrectly set its max length in some cases that may lead to truncated results returned. Fix: properly set CONVERT({INT, DECIMAL, REAL}, CHAR) result's max length.
-