- 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 2 commits
-
-
Bjorn Munch authored
-
Bjorn Munch authored
-
- 05 Jul, 2012 2 commits
-
-
Andrei Elkin authored
Fixes for BUG11761686 left a flaw that managed to slip away from testing. Only effective filtering branch was actually tested with a regression test added to rpl_filter_tables_not_exist. The reason of the failure is destuction of too early mem-root-allocated memory at the end of the deferred User-var's do_apply_event(). Fixed with bypassing free_root() in the deferred execution branch. Deallocation of created in do_apply_event() items is done by the base code through THD::cleanup_after_query() -> free_items() that the parent Query can't miss. sql/log_event.cc: Do not call free_root() in case the deferred User-var event. Necessary methods to the User-var class are added, do_apply_event() refined. sql/log_event.h: Necessary methods to avoid destoying mem-root-based memory at User-var applying are defined.
-
Georgi Kodinov authored
HANDLE_FATAL_SIGNAL IN STRNLEN Fixed the following bounds checking problems : 1. in check_if_legal_filename() make sure the null terminated string is long enough before accessing the bytes in it. Prevents pottential read-past-buffer-end 2. in my_wc_mb_filename() of the filename charset check for the end of the destination buffer before sending single byte characters into it. Prevents write-past-end-of-buffer (and garbaling stack in the cases reported here) errors. Added test cases.
-
- 03 Jul, 2012 1 commit
-
-
Rohit Kalhans authored
This is a followup patch for the bug enabling the test i_binlog.binlog_mysqlbinlog_file_write.test this was disabled in mysql trunk and mysql 5.5 as in the release build mysqlbinlog was not debug compiled whereas the mysqld was. Since have_debug.inc script checks only for mysqld to be debug compiled, the test was not being skipped on release builds. We resolve this problem by creating a new inc file mysqlbinlog_have_debug.inc which checks exclusively for mysqlbinlog to be debug compiled. if not it skips the test. mysql-test/include/mysqlbinlog_have_debug.inc: new inc file to check if mysqlbinlog is debug compiled.
-
- 29 Jun, 2012 1 commit
-
-
Gleb Shchepa authored
-
- 28 Jun, 2012 1 commit
-
-
Georgi Kodinov authored
Several fixes : * sql-common/client.c Added a validity check of the fields metadata packet sent by the server. Now libmysql will check if the length of the data sent by the server matches what's expected by the protocol before using the data. * client/mysqltest.cc Fixed the error handling code in mysqltest to avoid sending new commands when the reading the result set failed (and there are unread data in the pipe). * sql_common.h + libmysql/libmysql.c + sql-common/client.c unpack_fields() now generates a proper error when it fails. Added a new argument to this function to support the error generation. * sql/protocol.cc Added a debug trigger to cause the server to send a NULL insted of the packet expected by the client for testing purposes.
-
- 29 Jun, 2012 2 commits
-
-
Jon Olav Hauglid authored
This patch fixes various compilation warnings of the type "error: narrowing conversion of 'x' from 'datatype1' to 'datatype2'
-
Gleb Shchepa authored
Print the warning(note): YEAR(x) is deprecated and will be removed in a future release. Please use YEAR(4) instead on "CREATE TABLE ... YEAR(x)" or "ALTER TABLE MODIFY ... YEAR(x)", where x != 4
-
- 28 Jun, 2012 1 commit
-
-
Norvald H. Ryeng authored
-
- 26 Jun, 2012 1 commit
-
-
Kent Boortz authored
a multiple definition of 'THD::clear_error()' in (at least) libmysqld.a(lib_sql.o) and libmysqld.a(libfederated_a-ha_federated.o). Patch provided by Ramil Kalimullin.
-
- 21 Jun, 2012 1 commit
-
-
unknown authored
We set correct cmp_context during preparation to avoid changing it later by Item_field::equal_fields_propagator. (see mysql bugs #57135 #57692 during merging)
-
- 23 Jun, 2012 1 commit
-
-
Igor Babaev authored
The bug was the result of the incomplete fix for bug lp bug 1008293.
-
- 21 Jun, 2012 1 commit
-
-
Joerg Bruehe authored
-
- 20 Jun, 2012 2 commits
-
-
Kent Boortz authored
-
Kent Boortz authored
-
- 19 Jun, 2012 2 commits
-
-
Harin Vadodaria authored
INC_HOST_ERRORS() IS CALLED. Description: Reverting patch 3755 for bug#11753779
-
Igor Babaev authored
Virtual columns of ENUM and SET data types were not supported properly in the original patch that introduced virtual columns into MariaDB 5.2. The problem was that for any virtual column the patch used the interval_id field of the definition of the column in the frm file as a reference to the virtual column expression. The fix stores the optional interval_id of the virtual column in the extended header of the virtual column expression.
-
- 18 Jun, 2012 1 commit
-
-
Norvald H. Ryeng authored
Problem: Some queries with subqueries and a HAVING clause that consists only of a column not in the select or grouping lists causes the server to crash. During parsing, an Item_ref is constructed for the HAVING column. The name of the column is resolved when JOIN::prepare calls fix_fields() on its having clause. Since the column is not mentioned in the select or grouping lists, a ref pointer is not found and a new Item_field is created instead. The Item_ref is replaced by the Item_field in the tree of HAVING clauses. Since the tree consists only of this item, the pointer that is updated is JOIN::having. However, st_select_lex::having still points to the Item_ref as the root of the tree of HAVING clauses. The bug is triggered when doing filesort for create_sort_index(). When find_all_keys() calls select->cond->walk() it eventually reaches Item_subselect::walk() where it continues to walk the having clauses from lex->having. This means that it finds the Item_ref instead of the new Item_field, and Item_ref::walk() tries to dereference the ref pointer, which is still null. The crash is reproducible only in 5.5, but the problem lies latent in 5.1 and trunk as well. Fix: After calling fix_fields on the having clause in JOIN::prepare(), set select_lex::having to point to the same item as JOIN::having. This patch also fixes a bug in 5.1 and 5.5 that is triggered if the query is executed as a prepared statement. The Item_field is created in the runtime arena when the query is prepared, and the pointer to the item is saved by st_select_lex::fix_prepare_information() and brought back as a dangling pointer when the query is executed, after the runtime arena has been reclaimed. Fix: Backport fix from trunk that switches to the permanent arena before calling Item_ref::fix_fields() in JOIN::prepare(). sql/item.cc: Set context when creating Item_field. sql/sql_select.cc: Switch to permanent arena and update select_lex->having.
-
- 15 Jun, 2012 1 commit
-
-
unknown authored
-