- 08 Jan, 2009 4 commits
-
-
Davi Arnaut authored
-
Mattias Jonsson authored
-
Timothy Smith authored
-
Timothy Smith authored
The binlog_innodb test was sensitive to what tests ran before it. Now run FLUSH STATUS before performing operations that need to be checked. sys_var_thd_ulong::update() was improperly casting an option value from ulonglong to ulong before comparing it to the max allowed value. On systems where ulong and ulonglong are of different size, this caused values greater than ULONG_MAX to wrap around (not be truncated to ULONG_MAX, which appears to have been the intention of the original coder), and caused some checks to work incorrectly. This wasn't generally visible to the user, because later checks would prevent the wrapped-around value from being used. But it caused warning messages to differ between 32- and 64-bit platforms. Fix is to just remove the cast. Also added a DBUG_ASSERT to ensure that the value really is capped properly before finally stuffing it into the ulong.
-
- 07 Jan, 2009 5 commits
-
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Patrick Crews authored
-
Vladislav Vaintroub authored
-
Davi Arnaut authored
locking type of temp table The problem is that INSERT INTO .. SELECT FROM .. and CREATE TABLE .. SELECT FROM a temporary table could inadvertently overwrite the locking type of the temporary table. The lock type of temporary tables should be a write lock by default. The solution is to reset the lock type of temporary tables back to its default value after they are used in a statement. mysql-test/r/innodb_mysql.result: Add test case result for Bug#41348 mysql-test/r/temp_table.result: Add test case result for Bug#41348 mysql-test/t/innodb_mysql.test: Add test case for Bug#41348 mysql-test/t/temp_table.test: Add test case for Bug#41348 sql/sql_base.cc: Allow the lock type of temp tables to be overwritten now that the the value is being restored once the table is marked as free for re-use. This makes the behavior consistent with that of non-temporary tables and avoids confusion.
-
- 05 Jan, 2009 6 commits
-
-
Patrick Crews authored
-
Georgi Kodinov authored
-
Patrick Crews authored
Added function to check for diff and return an error message if the utility is not present. Previously, the way we did this didn't work on Windows, but did work on *Nix systems.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
case.
-
- 31 Dec, 2008 1 commit
-
-
Gleb Shchepa authored
Execution of queries containing the CASE function of aggregate function like in "SELECT ... CASE ARGV(...) WHEN ..." crashed the server. The CASE function caches pointers to concrete comparison functions for an each pair of types of CASE-WHERE clause parameters, i.e. for the "CASE INT_RESULT WHERE REAL_RESULT THEN ... WHERE DECIMAL_RESULT ... END" function call it caches comparisons for INT_RESULT with REAL_RESULT and for INT_RESULT with DECIMAL_RESULT. Usually a result type is known after a call to the fix_fields function, however, the setup_copy_fields function call may wrap aggregate items with Item_copy_string that has STRING_RESULT result type, so setup_copy_fields may change argument result types of the CASE function after call to Item_func_case::fix_fields/fix_length_and_dec. Then the Item_func_case::find_item function tries to use comparison function for unexpected pair of the STRING_RESULT and some other type - that caused an assertion failure of server crash. The Item_func_case::fix_length_and_dec function has been modified to take into account possible STRING_RESULT result type in the presence of aggregate arguments of the CASE function. mysql-test/r/func_in.result: Added test case for bug #41363. mysql-test/t/func_in.test: Added test case for bug #41363. sql/item_cmpfunc.cc: Bug #41363: crash of mysqld on windows with aggregate in case The Item_func_case::fix_length_and_dec function has been modified to take into account possible STRING_RESULT result type in the presence of aggregate arguments of the CASE function.
-
- 30 Dec, 2008 5 commits
-
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
Sven Sandberg authored
Disabled rpl_binlog_corruption since it requires the new mtr, which only exists in 5.1-rpl / 6.0-rpl. Please re-enable the test in 5.1-rpl / 6.0-rpl. mysql-test/suite/rpl/t/disabled.def: Disabled rpl_binlog_corruption since it requires the new mtr, which only exists in 5.1-rpl / 6.0-rpl.
-
- 29 Dec, 2008 4 commits
-
-
Sven Sandberg authored
Problem: When an Incident_log_event contains a bad incident number on disk, the server crashes with an assertion. Fix: Don't validate input with assertions. Use errors. mysql-test/include/cleanup_fake_relay_log.inc: Added auxiliary file to restore things that setup_fake_relay_log.inc did. mysql-test/include/setup_fake_relay_log.inc: Added auxiliary file to setup replication from an existing relay log. mysql-test/std_data/bug40482-bin.000001: Binlog file for rpl.rpl_binlog_corruption mysql-test/suite/rpl/t/rpl_binlog_corruption.test: New test file. sql/log_event.cc: Check that the incident number is correct at the time the event is constructed. Do not assert it at the time it is printed. sql/log_event.h: Incident_log_event::is_valid() should verify that the incident number is valid. sql/rpl_constants.h: Incident numbers should be hard-coded, since they may appear in files.
-
Sergey Glukhov authored
The problem: data file can not be deleted on win because there is another opened instance of this file. Data file might be opened twice, on table opening stage and during write_row execution. We need to close both instances to satisfy Win. mysql-test/r/csv.result: test result mysql-test/t/csv.test: test case storage/csv/ha_tina.cc: The problem: data file can not be deleted on win because there is another opened instance of this file. Data file might be opened twice, on table opening stage and during write_row execution. We need to close both instances to satisfy Win.
-
Sergey Glukhov authored
-
Sergey Glukhov authored
Added global status variable 'Queries' which represents total amount of queries executed by server including statements executed by SPs. note: It's old behaviour of 'Questions' variable. mysql-test/r/status.result: test result mysql-test/t/status.test: test case sql/mysqld.cc: Added global status variable 'Queries' which represents total amount of queries executed by server including statements executed by SPs. note: It's old behaviour of 'Questions' variable. sql/sql_show.cc: Added global status variable 'Queries' which represents total amount of queries executed by server including statements executed by SPs. note: It's old behaviour of 'Questions' variable. sql/structs.h: Added global status variable 'Queries' which represents total amount of queries executed by server including statements executed by SPs. note: It's old behaviour of 'Questions' variable.
-
- 28 Dec, 2008 6 commits
-
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Mattias Jonsson authored
Problem was an errornous date that lead to end partition was before the start, leading to a crash. Solution was to check greater or equal instead of only equal between start and end partition. NOTE: partitioning pruning handles incorrect dates differently than index lookup, which can give different results in a partitioned table versus a non partitioned table for queries having 'bad' dates in the where clause. mysql-test/r/partition_pruning.result: Bug#40972: some sql execution lead the whole databse crashing Updated result file mysql-test/t/partition_pruning.test: Bug#40972: some sql execution lead the whole databse crashing Added test. sql/sql_partition.cc: Bug#40972: some sql execution lead the whole databse crashing There can be cases where the start/cur partition is greater than the end partition, so it must not continue, since that can lead to a crash.
-
Kent Boortz authored
-
Kent Boortz authored
-
Kent Boortz authored
-
- 24 Dec, 2008 8 commits
-
-
Sergey Glukhov authored
-
Sergey Glukhov authored
Table could be marked dependent because it is either 1) an inner table of an outer join, or 2) it is a part of STRAIGHT_JOIN. In case of STRAIGHT_JOIN table->maybe_null should not be assigned. The fix is to set st_table::maybe_null to 'true' only for those tables which are used in outer join. mysql-test/r/select.result: test result mysql-test/t/select.test: test case sql/sql_select.cc: Table could be marked dependent because it is either 1) an inner table of an outer join, or 2) it is a part of STRAIGHT_JOIN. In case of STRAIGHT_JOIN table->maybe_null should not be assigned. The fix is to set st_table::maybe_null to 'true' only for those tables which are used in outer join. sql/sql_select.h: added comment
-
Sergey Glukhov authored
-
Sergey Glukhov authored
init user->user struct with thd->security_ctx->priv_user context if user->user is not initializied mysql-test/r/grant.result: test result mysql-test/t/grant.test: test case sql/set_var.cc: init user->user struct with thd->security_ctx->priv_user context if user->user is not initializied
-
Sergey Glukhov authored
-
Sergey Glukhov authored
replace wild_case_compare with my_wildcmp which is multibyte safe function mysql-test/r/lowercase_utf8.result: test result mysql-test/t/lowercase_utf8-master.opt: test case mysql-test/t/lowercase_utf8.test: test case sql/sql_show.cc: replace wild_case_compare with my_wildcmp which is multibyte safe function
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
- 23 Dec, 2008 1 commit
-
-
Sergey Glukhov authored
On Winodws FN_DEVCHAR is ':' symbol. There is a check in mysql_create_table_no_lock() func on FN_DEVCHAR presence but this code is obsolete and unnecessary. So the fix is to remove unnecessary code. mysql-test/r/create.result: test result mysql-test/t/create.test: test case sql/sql_table.cc: On Winodws FN_DEVCHAR is ':' symbol. There is a check in mysql_create_table_no_lock() func on FN_DEVCHAR presence but this code is obsolete and unnecessary. So the fix is to remove unnecessary code.
-