- 30 Jun, 2010 2 commits
-
-
Staale Smedseng authored
-
Staale Smedseng authored
automatic reconnect A client with automatic reconnect enabled will see the error message "Lost connection to MySQL server during query" if the connection is lost between mysql_stmt_prepare() and mysql_stmt_execute(). The mysql_stmt_errno() number, however, is 0 -- not the corresponding value 2013. This patch checks for the case where the prepared statement has been pruned due to a connection loss (i.e., stmt->mysql has been set to NULL) during a call to cli_advanced_command(), and avoids changing the last_errno to the result of the last reconnect attempt.
-
- 29 Jun, 2010 1 commit
-
-
Martin Hansson authored
-
- 28 Jun, 2010 8 commits
-
-
Luis Soares authored
-
Davi Arnaut authored
-
Luis Soares authored
-
Davi Arnaut authored
-
Davi Arnaut authored
-
Davi Arnaut authored
-
Davi Arnaut authored
The default value of the myisam_max_extra_sort_file_size could be higher than the maximum accepted value, leading to warnings upon the server start. The solution is to simply set the value to the maximum value in a 32-bit built (2147483647, one less than the current). This should be harmless as the option is currently unused in 5.1.
-
Davi Arnaut authored
The problem was that a user could supply supply data in chunks via the COM_STMT_SEND_LONG_DATA command to prepared statement parameter other than of type TEXT or BLOB. This posed a problem since other parameter types aren't setup to handle long data, which would lead to a crash when attempting to use the supplied data. Given that long data can be supplied at any stage of a prepared statement, coupled with the fact that the type of a parameter marker might change between consecutive executions, the solution is to validate at execution time each parameter marker for which a data stream was provided. If the parameter type is not TEXT or BLOB (that is, if the type is not able to handle a data stream), a error is returned.
-
- 27 Jun, 2010 4 commits
-
-
Alfranio Correia authored
-
Alfranio Correia authored
-
DROP USER RENAME USER CURRENT_USER() ... GRANT ... TO CURRENT_USER() REVOKE ... FROM CURRENT_USER() ALTER DEFINER = CURRENT_USER() EVENTbut, When these statements are binlogged, CURRENT_USER() just is binlogged as 'CURRENT_USER()', it is not expanded to the real user name. When slave executes the log event, 'CURRENT_USER()' is expand to the user of slave SQL thread, but SQL thread's user name always NULL. This breaks the replication. After this patch, session's user will be written into query log events if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.
-
- 26 Jun, 2010 3 commits
-
-
Jon Olav Hauglid authored
-
Jon Olav Hauglid authored
This deadlock happened if DROP DATABASE was blocked due to an open HANDLER table from a different connection. While DROP DATABASE is blocked, it holds the LOCK_mysql_create_db mutex. This results in a deadlock if the connection with the open HANDLER table tries to execute a CREATE/ALTER/DROP DATABASE statement as they all try to acquire LOCK_mysql_create_db. This patch makes this deadlock scenario very unlikely by closing and marking for re-open all HANDLER tables for which there are pending conflicing locks, before LOCK_mysql_create_db is acquired. However, there is still a very slight possibility that a connection could access one of these HANDLER tables between closing/marking for re-open and the acquisition of LOCK_mysql_create_db. This patch is for 5.1 only, a separate and complete fix will be made for 5.5+. Test case added to schema.test.
-
Alexander Nozdrin authored
-
- 25 Jun, 2010 4 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
During creation of the table list of processed tables hidden I_S table 'VARIABLES' is erroneously added into the table list. it leads to ER_UNKNOWN_TABLE error in TABLE_LIST::add_table_to_list() function. The fix is to skip addition of hidden I_S tables into the table list.
-
- 24 Jun, 2010 13 commits
-
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
-
Martin Hansson authored
-
Martin Hansson authored
require O(#scans) memory When an index merge operation was restarted, it would re-allocate the Unique object controlling the duplicate row ID elimination. Fixed by making the Unique object a member of QUICK_INDEX_MERGE_SELECT and thus reusing it throughout the lifetime of this object.
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
file .\filesort.cc, line 149 (part II) Problem: the server didn't disregard sort order for some zero length tuples. Fix: skip sort order in such a case (zero length NOT NULL string functions).
-
- 23 Jun, 2010 2 commits
-
-
sunanda authored
-
-
- 22 Jun, 2010 3 commits
-
-
Alexey Kopytov authored
Incorrect handling of NULL arguments could lead to a crash on the IN or CASE operations when either NULL arguments were passed explicitly as arguments (IN) or implicitly generated by the WITH ROLLUP modifier (both IN and CASE). Item_func_case::find_item() assumed all necessary comparators to be instantiated in fix_length_and_dec(). However, in the presence of WITH ROLLUP modifier, arguments could be substituted with an Item_null leading to an "unexpected" STRING_RESULT comparator being invoked. In addition to the problem identical to the above, Item_func_in::val_int() could crash even with explicitly passed NULL arguments due to an optimization in fix_length_and_dec() leading to NULL arguments being ignored during comparators creation.
-
Vasil Dimov authored
-
Alexander Nozdrin authored
-