- 17 Dec, 2010 11 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Alexander Nozdrin authored
-
Jorgen Loland authored
make_join_select() in sql_select.cc Caused by incorrect ASSERT introduced by BUG#58456. Quick selects may have index == MAX_KEY if it merges indices.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Luis Soares authored
Automerge from mysql-5.1-bugteam.
-
Luis Soares authored
Post-push fixes: - fixed platform dependent result files - appeasing valgrind warnings: Fault injection was also uncovering a previously existing potential mem leaks. For BUG#46166 testing purposes, fixed by forcing handling the leak when injecting faults.
-
- 16 Dec, 2010 11 commits
-
-
Luis Soares authored
-
Luis Soares authored
Merging to latest mysql-5.5-bugteam.
-
Luis Soares authored
Merging to latest mysql-5.1-bugteam.
-
Alexander Nozdrin authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Jorgen Loland authored
in opt_range.h In this bug, there are two alternative access plans: * Index merge range access * Const ref access best_access_path() decided that the ref access was preferrable, but make_join_select() still decided to point SQL_SELECT::quick to the index merge because the table had type==JT_CONST which was not handled. At the same time the table's ref.key still referred to the index the ref access would use indicating that ref access should be used. In this state, different parts of the optimizer code have different perceptions of which access path is in use (ref or range). test_if_skip_sort_order() was called to check if the ref access needed ordering, but test_if_skip_sort_order() got confused and requested the index merge to return records in sorted order. Index merge cannot do this, and fired an ASSERT. The fix is to take join_tab->type==JT_CONST into concideration when make_join_select() decides whether or not to use the range access method.
-
Jonathan Perkin authored
-
Jon Olav Hauglid authored
temptable views The TABLE::key_read field indicates if the optimizer has found that row retrieval only should access the index tree. The triggered assert inside close_thread_table() checks that this field has been reset when the table is about to be closed. During normal execution, these fields are reset right before tables are closed at the end of mysql_execute_command(). But in the case of errors, tables are closed earlier. The patch for Bug#52044 refactored the open tables code so that close_thread_tables() is called immediately if opening of tables fails. At this point in the execution, it could happend that all TABLE::key_read fields had not been properly reset, therefore triggering the assert. The problematic statement in this case was EXPLAIN where the query accessed two derived tables and where the first derived table was processed successfully while the second derived table was not. Since it was an EXPLAIN, TABLE::key_read fields were not reset after successful derived table processing since the state needs to be accessible afterwards. When processing of the second derived table failed, it's corresponding SELECT_LEX_UNIT was cleaned, which caused it's TABLE::key_read fields to be reset. Since processing failed, the error path of open_and_lock_tables() was entered and close_thread_tables() was called. The assert was then triggered due to the TABLE::key_read fields set during processing of the first derived table. This patch fixes the problem by adding a new derived table processor, mysql_derived_cleanup() that is called after mysql_derived_filling(). It causes cleanup of all SELECT_LEX_UNITs to be called, resetting all relevant TABLE::key_read fields. Test case added to derived.test.
-
Jonathan Perkin authored
Allow users to build without aio if they really want to, by passing -DIGNORE_AIO_CHECK to cmake.
-
- 15 Dec, 2010 7 commits
-
-
Davi Arnaut authored
The problem is a race between a session closing its vio (i.e. after a COM_QUIT) at the same time it is being killed by another thread. This could trigger a assertion in vio_close() as the two threads could end up closing the same vio, at the same time. This could happen due to the implementation of SIGNAL_WITH_VIO_CLOSE, which closes the vio of the thread being killed. The solution is to serialize the close of the Vio under LOCK_thd_data, which protects THD data. No regression test is added as this is essentially a debug issue and the test case would be quite convoluted as we would need to synchronize a session that is being killed -- which is a bit difficult since debug sync points code does not synchronize killed sessions.
-
Davi Arnaut authored
The MYSQL_LOG::open member function does not take a PSI key file argument when the PSI interface is not present.
-
Davi Arnaut authored
automatically to place a dependency on the VERSION file.
-
Davi Arnaut authored
option for specific compilers Reorganize the maintainer mode cmake code to allow options for specific compilers. For now, enable -Wcheck for ICC, but do not turn warnings into errors.
-
Davi Arnaut authored
initialization to specific functions. Also, remove a large block of white space. There shouldn't be any functional change.
-
Alexander Barkov authored
Problem: when inserting supplementary characters to an UCS2 column, character was silently shrinked to 16-bit value. Fix: produce a warning on attempt to insert a supplementary character, and convert to question mark. @ mysql-test/r/ctype_many.result @ mysql-test/t/ctype_many.test Adding tests @ strings/ctype-ucs2.c Check if wc is greater than the highest value supported (0xFFFF), return MY_CS_ILUNI if true.
-
Sunanda Menon authored
-
- 14 Dec, 2010 11 commits
-
-
Gleb Shchepa authored
-
Gleb Shchepa authored
-
Gleb Shchepa authored
Original revid: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l > Bug #54476: crash when group_concat and 'with rollup' in > prepared statements > > Using GROUP_CONCAT() together with the WITH ROLLUP modifier > could crash the server. > > The reason was a combination of several facts: > > 1. The Item_func_group_concat class stores pointers to ORDER > objects representing the columns in the ORDER BY clause of > GROUP_CONCAT(). > > 2. find_order_in_list() called from > Item_func_group_concat::setup() modifies the ORDER objects so > that their 'item' member points to the arguments list > allocated in the Item_func_group_concat constructor. > > 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of > the original Item_func_group_concat object could be created by > using the Item_func_group_concat::Item_func_group_concat(THD > *thd, Item_func_group_concat *item) copy constructor. The > latter essentially creates a shallow copy of the source > object. Memory for the arguments array is allocated on > thd->mem_root, but the pointers for arguments and ORDER are > copied verbatim. > > What happens in the test case is that when executing the query > for the first time, after a copy of the original > Item_func_group_concat object has been created by > JOIN::rollup_make_fields(), find_order_in_list() is called for > this new object. It then resolves ORDER BY by modifying the > ORDER objects so that they point to elements of the arguments > array which is local to the cloned object. When thd->mem_root > is freed upon completing the execution, pointers in the ORDER > objects become invalid. Those ORDER objects, however, are also > shared with the original Item_func_group_concat object which is > preserved between executions of a prepared statement. So the > first call to find_order_in_list() for the original object on > the second execution tries to dereference an invalid pointer. > > The solution is to create copies of the ORDER objects when > copying Item_func_group_concat to not leave any stale pointers > in other instances with different lifecycles.
-
Luis Soares authored
Automerging mysql-5.1-bugteam into mysql-5.5-bugteam.
-
Luis Soares authored
Autmoerging into latest mysql-5.1-bugteam.
-
Luis Soares authored
Addressing review comments.
-
Luis Soares authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
Bug#57913 large negative number to string conversion functions crash String object which is used as result container of the item has uninitialized 'str_charset' field. This object might be used later to preform some internal operations and str_charset field is involved in these operations. It leads to crash. The fix is to intialize str_charset in my_decimal2string() func.
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-