- 02 Nov, 2012 1 commit
-
-
unknown authored
-
- 01 Nov, 2012 1 commit
-
-
unknown authored
-
- 31 Oct, 2012 4 commits
-
-
unknown authored
-
Michael Widenius authored
mysql-test/r/partition.result: Added test case mysql-test/t/partition.test: Added test case sql/ha_partition.cc: Removed printing of not initialized variable storage/maria/ha_maria.cc: Don't copy variables that are not initialized
-
Michael Widenius authored
storage/maria/ma_test2.c: Problem was that rnd() generated bigger value than allocated array
-
unknown authored
-
- 09 Oct, 2012 1 commit
-
-
unknown authored
-
- 14 Oct, 2012 1 commit
-
-
unknown authored
Empty result after reading const tables now works for subqueries.
-
- 02 Oct, 2012 1 commit
-
-
unknown authored
Check ability of index to be NULL as it made in MyISAM. UNIQUE with NULL could have several NULL entries so we have to continue even if ve have found a row.
-
- 27 Sep, 2012 2 commits
- 26 Sep, 2012 3 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
unknown authored
- Fix some warnings in newer GCC (-Werror ...). - Fix wrong STACK_DIRECTION detected by configure due to compiler inlining.
-
- 25 Sep, 2012 1 commit
-
-
Sergei Golubchik authored
-
- 26 Sep, 2012 1 commit
-
-
unknown authored
-
- 24 Sep, 2012 2 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
- 14 Sep, 2012 1 commit
-
-
unknown authored
Analysis: The queries in question use the [unique | index]_subquery execution methods. These methods reuse the ref keys constructed by create_ref_for_key(). The way create_ref_for_key() works is that it doesn't store in ref.key_copy[] store_key elements that represent constants. In particular it doesn't store the store_key for NULL constants. The execution of [unique | index]_subquery calls subselect_uniquesubquery_engine::copy_ref_key, which in addition to copy the left IN argument into a index lookup key, is supposed to detect if the left IN argument contains NULLs. Since the store_key for the NULL constant is not copied into the key array, the null is not detected, and execution erroneously proceeds as if it should look for a complete match. Solution: The solution (unlike MySQL) is to reuse already computed information about NULL presence. Item_in_optimizer::val_int already finds out if the left IN operand contains NULLs. The fix propagates this to the execution methods subselect_[unique | index]subquery_engine::exec so it knows if there were NULL values independent of the presence of keys. In addition the patch siplifies copy_ref_key() and the logic that hanldes the case of NULLs in the left IN operand.
-
- 24 Aug, 2012 9 commits
-
-
unknown authored
-
unknown authored
-
unknown authored
-
unknown authored
-
Vladislav Vaintroub authored
-
unknown authored
-
unknown authored
-
unknown authored
-
unknown authored
Various places in the server replication code was incorrectly quoting strings, which could lead to incorrect SQL on the slave/mysqlbinlog.
-
- 22 Aug, 2012 3 commits
-
-
Sergei Golubchik authored
increase xtradb verson from 13.0 to 13.01
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
- 12 Jul, 2012 1 commit
-
-
Bjorn Munch authored
-
- 10 Jul, 2012 7 commits
-
-
unknown authored
No commit message
-
Andrei Elkin authored
-
Andrei Elkin authored
-
Bjorn Munch authored
-
Andrei Elkin authored
-
Sujatha Sivakumar authored
Problem: ======= The return value from my_b_write is ignored by: `my_b_write_quoted', `my_b_write_bit',`Query_log_event::print_query_header' Most callers of `my_b_printf' ignore the return value. `log_event.cc' has many calls to it. Analysis: ======== `my_b_write' is used to write data into a file. If the write fails it sets appropriate error number and error message through my_error() function call and sets the IO_CACHE::error == -1. `my_b_printf' function is also used to write data into a file, it internally invokes my_b_write to do the write operation. Upon success it returns number of characters written to file and on error it returns -1 and sets the error through my_error() and also sets IO_CACHE::error == -1. Most of the event specific print functions for example `Create_file_log_event::print', `Execute_load_log_event::print' etc are the ones which make several calls to the above two functions and they do not check for the return value after the 'print' call. All the above mentioned abuse cases deal with the client side. Fix: === As part of bug fix a check for IO_CACHE::error == -1 has been added at a very high level after the call to the 'print' function. There are few more places where the return value of "my_b_write" is ignored those are mentioned below. +++ mysys/mf_iocache2.c 2012-06-04 07:03:15 +0000 @@ -430,7 +430,8 @@ memset(buffz, '0', minimum_width - length2); else memset(buffz, ' ', minimum_width - length2); - my_b_write(info, buffz, minimum_width - length2); +++ sql/log.cc 2012-06-08 09:04:46 +0000 @@ -2388,7 +2388,12 @@ { end= strxmov(buff, "# administrator command: ", NullS); buff_len= (ulong) (end - buff); - my_b_write(&log_file, (uchar*) buff, buff_len); At these places appropriate return value handlers have been added. client/mysqlbinlog.cc: check for IO_CACHE::error == -1 has been added after the call to the event specific print functions mysys/mf_iocache2.c: Added handler to check the written value of `my_b_write' sql/log.cc: Added handler to check the written value of `my_b_write' sql/log_event.cc: Added error simulation statements in `Create_file_log_event::print` and `Execute_load_query_log_event::print' sql/rpl_utility.h: Removed the extra ';'
-
Bjorn Munch authored
-
- 09 Jul, 2012 1 commit
-
-
Bjorn Munch authored
-