- 15 Nov, 2010 2 commits
-
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
- 12 Nov, 2010 1 commit
-
-
Alexander Barkov authored
Problem: When GET_FORMAT() is called two times from the upper level function (e.g. LEAST in the bug report), on the second call "res= args[0]->val_str(...)" and str point to the same String object. 1. Fix: changing the order from - get val_str into tmp_value then convert to str to - get val_str into str then convert to tmp_value The new order is more correct: the purpose of "str" parameter is exactly to call val_str() for arguments. The purpose of String class members (like tmp_value) is to do further actions on the result. Doing it in the other way around give unexpected surprises. 2. Using str_value instead of str to do padding, for the same reason.
-
- 11 Nov, 2010 1 commit
-
-
Alexander Barkov authored
Bug#57820 extractvalue crashes Problem: ExtractValue and Replace crashed in some cases due to invalid handling of empty and NULL arguments. Per file comments: @mysql-test/r/ctype_ujis.result @mysql-test/r/xml.result @mysql-test/t/ctype_ujis.test @mysql-test/t/xml.test Adding tests @sql/item_strfunc.cc Make sure Item_func_replace::val_str safely handles empty strings. @sql/item_xmlfunc.cc set null_value if nodeset_func returned NULL, which is possible when the second argument is an unset user variable.
-
- 08 Nov, 2010 3 commits
-
-
Sergey Glukhov authored
-
Sergey Glukhov authored
backport from 5.1
-
Sergey Glukhov authored
Problem: a flaw (derefencing a NULL pointer) in the LIKE optimization code may lead to a server crash in some rare cases. Fix: check the pointer before its dereferencing.
-
- 03 Nov, 2010 2 commits
-
-
karen.langford@oracle.com authored
-
Georgi Kodinov authored
-
- 01 Nov, 2010 2 commits
-
-
karen.langford@oracle.com authored
-
Sergey Glukhov authored
-
- 29 Oct, 2010 7 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Sergey Glukhov authored
Lines below which were added in the patch for Bug#56814 cause this crash: + if (table->table) + table->table->maybe_null= FALSE; Consider following test case: -- CREATE TABLE t1(f1 INT NOT NULL); INSERT INTO t1 VALUES (16777214),(0); SELECT COUNT(*) FROM t1 LEFT JOIN t1 t2 ON 1 WHERE t2.f1 > 1 GROUP BY t2.f1; DROP TABLE t1; -- We set TABLE::maybe_null to FALSE for t2 table and in create_tmp_field() we create appropriate tmp table field using create_tmp_field_from_item() function instead of create_tmp_field_from_field. As a result we have LONGLONG field. As we have GROUP BY clause we calculate group buffer length, see calc_group_buffer(). Item from group list which is used for calculation refer to the field from real tables and have LONG type. So group buffer length become insufficient for storing of LONGLONG value. It leads to overwriting of wrong memory area in do_field_int() function which is called from end_update(). After some investigation I found out that create_tmp_field_from_item() is used only for OLAP grouping and can not be used for common grouping as it could be an incompatibility between tmp table fields and group buffer length. We can not remove create_tmp_field_from_item() call from create_tmp_field as OLAP needs it and we can not use this function for common grouping. So we should remove setting TABLE::maybe_null to FALSE from simplify_joins(). In this case we'll get wrong behaviour of list_contains_unique_index() back. To fix it we could use Field::real_maybe_null() check instead of Field::maybe_null() and add addition check of TABLE_LIST::outer_join.
-
Vasil Dimov authored
-
Sergey Glukhov authored
The problem is caused by bug49487 fix and became visible after after bug56679 fix. Items are cleaned up and set to unfixed state after filling derived table. So we can not rely on item::fixed state in Item_func_group_concat::print and we can not use 'args' array as items there may be cleaned up. The fix is always to use orig_args array of items as it always should contain the correct data.
-
- 28 Oct, 2010 2 commits
-
-
Calvin Sun authored
On Windows, the parameter for number of bytes passed into WriteFile() and ReadFile() is DWORD. Casting is needed to silence the warning on 64-bit Windows. Also, adding several asserts to ensure the variable for number of bytes is no more than 32 bits, even on 64-bit Windows. This is for InnoDB Plugin. rb://415 Approved by: Inaam
-
Calvin Sun authored
On Windows, the parameter for number of bytes passed into WriteFile() and ReadFile() is DWORD. Casting is needed to silence the warning on 64-bit Windows. Also, adding several asserts to ensure the variable for number of bytes is no more than 32 bits, even on 64-bit Windows. This is for built-in InnoDB. rb://415 Approved by: Inaam
-
- 27 Oct, 2010 3 commits
-
-
Sergey Glukhov authored
The problem is dividing by const value when the result is out of supported range. The fix: -return LONGLONG_MIN if the result is out of supported range for DIV operator. -return 0 if divisor is -1 for MOD operator.
-
Vasil Dimov authored
-
Anitha Gopi authored
-
- 26 Oct, 2010 1 commit
-
-
Inaam Rana authored
rb://498 Fix handling of update_undo_logs at trx commit. Previously, when rseg->update_undo_list grows beyond 500 the update_undo_logs were marked with state TRX_UNDO_TO_FREE which should have been TRX_UNDO_TO_PURGE. Approved by: Sunny Bains
-
- 25 Oct, 2010 3 commits
-
-
Bjorn Munch authored
-
Jimmy Yang authored
Approved by Sunny Bains
-
Jimmy Yang authored
Approved by Sunny Bains
-
- 23 Oct, 2010 1 commit
-
-
"Grantor" columns' data is lost when replicating mysql.tables_priv. Slave SQL thread used its default user ''@'' as the grantor of GRANT|REVOKE statements executing on it. In this patch, current user is put in query log event for all GRANT and REVOKE statement, SQL thread uses the user in query log event as grantor.
-
- 21 Oct, 2010 4 commits
-
-
Bjorn Munch authored
Simplified cases where a select was used to compare variable against ''
-
Rows events were applied wrongly on the temporary table with the same name. But rows events are generated only for base tables. As temporary table's data never be binlogged on row mode. Normally, base table of the same name cannot be updated if a temporary table has the same name. But there are two cases which can generate rows events on the base table of same name. Case1: 'CREATE TABLE ... SELECT' statement. In mixed format, it will generate rows events if it is unsafe. Case2: Drop a transactional temporary table in a transaction (happens only on 5.5+). BEGIN; DROP TEMPORARY TABLE t1; # t1 is a InnoDB table INSERT INTO t1 VALUES(rand()); # t1 is a MyISAM table COMMIT; 'DROP TEMPORARY TABLE' will be put in the transaction cache and binlogged after the rows events generated by the 'INSERT' statement. After this patch, slave opens only base table when applying a rows event.
-
Jimmy Yang authored
index or foreign key Approved by Sunny Bains
-
Jimmy Yang authored
or foreign key Fix approved by Sunny Bains
-
- 20 Oct, 2010 6 commits
-
-
Davi Arnaut authored
Fix assorted warnings that are generated in optimized builds. Most of it is silencing variables that are set but unused. This patch also introduces the MY_ASSERT_UNREACHABLE macro which helps the compiler to deduce that a certain piece of code is unreachable.
-
Davi Arnaut authored
Fix assorted compiler warnings.
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Bjorn Munch authored
Limited to actual bug fix, fixing a while condition Again confirmed on Linux PPC and on AIX 5.3
-
- 19 Oct, 2010 2 commits
-
-
Davi Arnaut authored
Tag or remove unused arguments and variables.
-
Davi Arnaut authored
Ensure that fdatasync is properly declared as on Mac OS X, the function is available but there is no prototype. Also, port a fix for a warning from the InnoDB plugin over to the builtin.
-