An error occurred fetching the project authors.
- 13 Aug, 2010 1 commit
-
-
Georgi Kodinov authored
The server was not checking for errors generated during the execution of Item::val_xxx() methods when copying data to the group, order, or distinct temp table's row. Fixed by extending the copy_funcs() to return an error code and by checking for that error code on the places copy_funcs() is called. Test case added.
-
- 09 Aug, 2010 1 commit
-
-
Jon Olav Hauglid authored
INSERT IGNORE ... SELECT ... UNION SELECT ... This assert was triggered by INSERT IGNORE ... SELECT. The assert checks that a statement either sends OK or an error to the client. If the bug was triggered on release builds, it caused OK to be sent to the client instead of the correct error message (in this case ER_FIELD_SPECIFIED_TWICE). The reason the assert was triggered, was that lex->no_error was set to TRUE during JOIN::optimize() because of IGNORE. This causes all errors to be ignored. However, not all errors can be ignored. Some, such as ER_FIELD_SPECIFIED_TWICE will cause the INSERT to fail no matter what. But since lex->no_error was set, the critical errors were ignored, the INSERT failed and neither OK nor the error message was sent to the client. This patch fixes the problem by temporarily turning off lex->no_error in places where errors cannot be ignored during processing of INSERT ... SELECT. Test case added to insert.test.
-
- 19 Jul, 2010 1 commit
-
-
Jon Olav Hauglid authored
This assert checks that the server does not try to send OK to the client if there has been some error during processing. This is done to make sure that the error is in fact sent to the client. The problem was that view errors during processing of WHERE conditions in UPDATE statements where not detected by the update code. It therefore tried to send OK to the client, triggering the assert. The bug was only noticeable in debug builds. This patch fixes the problem by making sure that the update code checks for errors during condition processing and acts accordingly.
-
- 09 Jul, 2010 1 commit
-
-
Sergey Glukhov authored
The problem there is that HAVING condition evaluates const parts of condition despite the condition has references on aggregate functions. Table t1 became const tables after make_join_statistics and table1.pk = 1, HAVING is transformed into MAX(1) < 7 and taken away from HAVING. The fix is to skip evaluation of HAVING conts parts if HAVING condition has references on aggregate functions. mysql-test/r/having.result: test case mysql-test/t/having.test: test case sql/sql_select.cc: skip evaluation of HAVING conts parts if HAVING condition has references on aggregate functions.
-
- 30 Jun, 2010 1 commit
-
-
Sergey Glukhov authored
The problem is that QUICK_SELECT_DESC behaviour depends on used_key_parts value which can be bigger than selected best_key_parts value if an engine supports clustered key. But used_key_parts is overwritten with best_key_parts value that prevents from correct selection of index access method. The fix is to preserve used_key_parts value for further use in QUICK_SELECT_DESC. mysql-test/r/innodb_mysql.result: test case mysql-test/t/innodb_mysql.test: test case sql/sql_select.cc: preserve used_key_parts value for further use in QUICK_SELECT_DESC
-
- 24 Jun, 2010 1 commit
-
-
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). mysql-test/r/select.result: Fix for bug #54459: Assertion failed: param.sort_length, file .\filesort.cc, line 149 (part II) - test result. mysql-test/t/select.test: Fix for bug #54459: Assertion failed: param.sort_length, file .\filesort.cc, line 149 (part II) - test case. sql/sql_select.cc: Fix for bug #54459: Assertion failed: param.sort_length, file .\filesort.cc, line 149 (part II) - disregard sort order for zero length NOT NULL string functions along with zero length NOT NULL fields.
-
- 22 Jun, 2010 1 commit
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3351.41.1 > revision-id: alexey.kopytov@sun.com-20100430111048-jdls6ofn4kkmpt09 > parent: sergey.glukhov@sun.com-20100329134249-03wyhzp5k92dzhcb > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com> > branch nick: my51-bug48419 > timestamp: Fri 2010-04-30 15:10:48 +0400 > message: > Bug #48419: another explain crash.. > > WHERE predicates containing references to empty tables in a > subquery were handled incorrectly by the optimizer when > executing EXPLAIN. As a result, the optimizer could try to > evaluate such predicates rather than just stop with > "Impossible WHERE noticed after reading const tables" as > it would do in a non-subquery case. This led to valgrind > errors and crashes. > > Fixed the code checking the above condition so that subqueries > are not excluded and hence are handled in the same way as top > level SELECTs.
-
- 10 Jun, 2010 1 commit
-
-
Davi Arnaut authored
strict aliasing violations. One somewhat major source of strict-aliasing violations and related warnings is the SQL_LIST structure. For example, consider its member function `link_in_list` which takes a pointer to pointer of type T (any type) as a pointer to pointer to unsigned char. Dereferencing this pointer, which is done to reset the next field, violates strict-aliasing rules and might cause problems for surrounding code that uses the next field of the object being added to the list. The solution is to use templates to parametrize the SQL_LIST structure in order to deference the pointers with compatible types. As a side bonus, it becomes possible to remove quite a few casts related to acessing data members of SQL_LIST. sql/handler.h: Use the appropriate template type argument. sql/item.cc: Remove now-unnecessary cast. sql/item_subselect.cc: Remove now-unnecessary casts. sql/item_sum.cc: Use the appropriate template type argument. Remove now-unnecessary cast. sql/mysql_priv.h: Move SQL_LIST structure to sql_list.h Use the appropriate template type argument. sql/sp.cc: Remove now-unnecessary casts. sql/sql_delete.cc: Use the appropriate template type argument. Remove now-unnecessary casts. sql/sql_derived.cc: Remove now-unnecessary casts. sql/sql_lex.cc: Remove now-unnecessary casts. sql/sql_lex.h: SQL_LIST now takes a template type argument which must match the type of the elements of the list. Use forward declaration when the type is not available, it is used in pointers anyway. sql/sql_list.h: Rename SQL_LIST to SQL_I_List. The template parameter is the type of object that is stored in the list. sql/sql_olap.cc: Remove now-unnecessary casts. sql/sql_parse.cc: Remove now-unnecessary casts. sql/sql_prepare.cc: Remove now-unnecessary casts. sql/sql_select.cc: Remove now-unnecessary casts. sql/sql_show.cc: Remove now-unnecessary casts. sql/sql_table.cc: Remove now-unnecessary casts. sql/sql_trigger.cc: Remove now-unnecessary casts. sql/sql_union.cc: Remove now-unnecessary casts. sql/sql_update.cc: Remove now-unnecessary casts. sql/sql_view.cc: Remove now-unnecessary casts. sql/sql_yacc.yy: Remove now-unnecessary casts. storage/myisammrg/ha_myisammrg.cc: Remove now-unnecessary casts.
-
- 27 May, 2010 1 commit
-
-
Sergey Glukhov authored
There are two problems: 1. In simplify_joins function we calculate table dependencies. If STRAIGHT_JOIN hint is used for whole SELECT we do not count it and as result some dependendecies might be lost. It leads to incorrect table order which is returned by join_tab_cmp_straight() function. 2. make_join_statistics() calculate the transitive closure for relations a particular JOIN_TAB is 'dependent on'. We aggregate the dependent table_map of a JOIN_TAB by adding dependencies from other tables which we depend on. However, this may also cause new dependencies to be available after we have completed processing a certain JOIN_TAB. Both these problems affect condition pushdown and as result condition might be pushed into wrong table which leads to crash or even omitted which leads to wrong result. The fix: 1. Use modified 'transitive closure' algorithm provided by Ole John Aske 2. Update table dependences in simplify_joins according to global STRAIGHT_JOIN hint. Note: the patch also fixes bugs 46091 & 51492 mysql-test/r/join_outer.result: test case mysql-test/t/join_outer.test: test case sql/sql_select.cc: 1. Use modified 'transitive closure' algorithm provided by Ole John Aske 2. Update table dependences in simplify_joins according to global STRAIGHT_JOIN hint.
-
- 07 May, 2010 1 commit
-
-
Sergey Glukhov authored
The fix actually reverts the change introduced by the patch for bug 51494. The fact is that patches for bugs 52177&48419 fix bugs 51194&50575 as well. mysql-test/r/innodb_mysql.result: test case mysql-test/t/innodb_mysql.test: test case sql/sql_select.cc: reverted wrong fix for bug 51494
-
- 06 May, 2010 1 commit
-
-
Martin Hansson authored
greedy_search optimizer_search_depth=0 The algorithm inside restore_prev_nj_state failed to properly update the counters within the NESTED_JOIN tree. The counter was decremented each time a table in the node was removed from the QEP, the correct thing to do being only to decrement it when the last table in the child node was removed from the plan. This lead to node counters getting negative values and the plan thus appeared impossible. An assertion caught this. Fixed by not recursing up the tree unless the last table in the join nest node is removed from the plan
-
- 30 Apr, 2010 1 commit
-
-
Alexey Kopytov authored
WHERE predicates containing references to empty tables in a subquery were handled incorrectly by the optimizer when executing EXPLAIN. As a result, the optimizer could try to evaluate such predicates rather than just stop with "Impossible WHERE noticed after reading const tables" as it would do in a non-subquery case. This led to valgrind errors and crashes. Fixed the code checking the above condition so that subqueries are not excluded and hence are handled in the same way as top level SELECTs. mysql-test/r/explain.result: Added a test case for bug #48419. mysql-test/r/ps.result: Updated test results to take the new (and more correct) "Extra" comments in execution plans. mysql-test/t/explain.test: Added a test case for bug #48419. sql/sql_select.cc: There is no point in excluding subqueries from checking for identically false WHERE conditions.
-
- 26 Apr, 2010 1 commit
-
-
Alexey Kopytov authored
The problem was in an incorrect debug assertion. The expression used in the failing assertion states that when finding references matching ORDER BY expressions, there can be only one reference to a single table. But that does not make any sense, all test cases for this bug are valid examples with multiple identical WHERE expressions referencing the same table which are also present in the ORDER BY list. Fixed by removing the failing assertion. We also have to take care of the 'found' counter so that we count multiple references only once. We rely on this fact later in eq_ref_table(). mysql-test/r/join.result: Added a test case for bug #50335. mysql-test/t/join.test: Added a test case for bug #50335. sql/sql_select.cc: Removing the assertion in eq_ref_table() as it does not make any sense. We also have to take care of the 'found' counter so that we count multiple references only once. We rely on this fact later in eq_ref_table().
-
- 15 Apr, 2010 1 commit
-
-
Georgi Kodinov authored
union...order by (select... where...) The problem is mysql is trying to materialize and cache the scalar sub-queries at JOIN::optimize even for EXPLAIN where the number of columns is totally different from what's expected. Fixed by not executing the scalar subqueries for EXPLAIN.
-
- 05 Apr, 2010 1 commit
-
-
Sergey Glukhov authored
The problem is that we can not use make_cond_for_table(). This function relies on used_tables() condition which is not set properly for subqueries. As result subquery is not filtered out. The fix is to use remove_eq_conds() function instead of make_cond_for_table() func. 'remove_eq_conds()' algorithm relies on const_item() value and it allows to handle subqueries in right way. mysql-test/r/having.result: test case mysql-test/t/having.test: test case sql/sql_select.cc: The fix is to use remove_eq_conds() function instead of make_cond_for_table() function.
-
- 26 Mar, 2010 1 commit
-
-
Sergey Glukhov authored
The crash is the result of an attempt made by JOIN::optimize to evaluate the WHERE condition when no records have been actually read. The fix is to remove erroneous 'outer_join' variable check. mysql-test/r/join.result: test result mysql-test/t/join.test: test case sql/sql_select.cc: removed erroneous 'outer_join' variable check.
-
- 24 Mar, 2010 6 commits
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3333.1.31 > revision-id: joro@sun.com-20091223104518-o29t0i3thgs7wgm1 > parent: sergey.glukhov@sun.com-20100205093946-bx1hsljxlm12h7uf > committer: Georgi Kodinov <joro@sun.com> > branch nick: B39022-5.1-bugteam > timestamp: Wed 2009-12-23 12:45:18 +0200 > message: > Bug #39022: Mysql randomly crashing in lock_sec_rec_cons_read_sees > > flush_cached_records() was not correctly checking for errors after calling > Item::val_xxx() methods. The expressions may contain subqueries > or stored procedures that cause errors that should stop the statement. > Fixed by correctly checking for errors and propagating them up the call stack. > ------------------------------------------------------------ > revno: 3358 > revision-id: sergey.glukhov@sun.com-20100226113925-mxwn1hfxe3l8khc4 > parent: gshchepa@mysql.com-20100225191311-1x71dkk0h5e1alvx > committer: Sergey Glukhov <Sergey.Glukhov@sun.com> > branch nick: mysql-5.1-bugteam > timestamp: Fri 2010-02-26 15:39:25 +0400 > message: > Bug#50995 Having clause on subquery result produces incorrect results. > The problem is that cond->fix_fields(thd, 0) breaks > condition(cuts off 'having'). The reason of that is > that NULL valued Item pointer is present in the > middle of Item list and it breaks the Item processing > loop.
-
MySQL Build Team authored
Backporting of 5.1.43sp1 release, files mysql-test/r/bug39022.result, mysql-test/t/bug39022.test added
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3333.1.11 [merge] > revision-id: joro@sun.com-20100201115030-hgvq6489bt0w3rty > parent: li-bing.song@sun.com-20100130124925-o6sfex42b6noyc6x > parent: joro@sun.com-20100201114016-jylx4hivgqbs0vg2 > committer: Georgi Kodinov <joro@sun.com> > branch nick: test-5.1-bugteam > timestamp: Mon 2010-02-01 13:50:30 +0200 > message: > merge > ------------------------------------------------------------ > Use --include-merges or -n0 to see merged revisions.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3333.1.7 [merge] > revision-id: ramil@mysql.com-20100129110849-1nm85j95594epnme > parent: joro@sun.com-20100129093628-sze9cv0neu0xbabm > parent: ramil@mysql.com-20100129091757-81r640na2t5bzbiz > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: mysql-5.1-bugteam > timestamp: Fri 2010-01-29 15:08:49 +0400 > message: > Auto-merge. > ------------------------------------------------------------ > Use --include-merges or -n0 to see merged revisions.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3324 > revision-id: joro@sun.com-20091223151122-ada73up1yydh0emt > parent: joro@sun.com-20100119124841-38vva51cuq3if7dc > committer: Georgi Kodinov <joro@sun.com> > branch nick: B49512-5.1-bugteam > timestamp: Wed 2009-12-23 17:11:22 +0200 > message: > Bug #49512 : subquery with aggregate function crash > subselect_single_select_engine::exec() > > When a subquery doesn't need to be evaluated because > it returns only aggregate functions and these aggregates > can be calculated from the metadata about the table it > was not updating all the relevant members of the JOIN > structure to reflect that this is a constant query. > This caused problems to the enclosing subquery > ('<> SOME' in the test case above) trying to read some > data about the tables. > > Fixed by setting const_tables to the number of tables > when the SELECT is optimized away.
-
Sergey Glukhov authored
The crash happens because greedy_serach can not determine best plan due to wrong inner table dependences. These dependences affects join table sorting which performs before greedy_search starting. In our case table which has real 'no dependences' should be put on top of the list but it does not happen as inner tables have no dependences as well. The fix is to exclude RAND_TABLE_BIT mask from condition which checks if table dependences should be updated. mysql-test/r/join.result: test result mysql-test/t/join.test: test case sql/sql_select.cc: RAND_TABLE_BIT mask should not be counted as it prevents update of inner table dependences. For example it might happen if RAND() function is used in JOIN ON clause.
-
- 19 Mar, 2010 2 commits
-
-
Sergey Glukhov authored
The problem is that when we make conditon for grouped result const part of condition is cut off. It happens because some parts of 'having' condition which refer to outer join become const after make_join_statistics. These parts may be lost during further having condition transformation in JOIN::exec. The fix is adding 'having' condition check for const tables after make_join_statistics is performed. mysql-test/r/having.result: test case mysql-test/t/having.test: test result sql/sql_select.cc: added 'having' condition check for const tables after make_join_statistics is performed.
-
Sergey Glukhov authored
The crash happens because of discrepancy between values of conts_tables and join->const_table_map(make_join_statisctics). Calculation of conts_tables used condition with HA_STATS_RECORDS_IS_EXACT flag check. Calculation of join->const_table_map does not use this flag check. In case of MERGE table without union with index the table does not become const table and thus join_read_const_table() is not called for the table. join->const_table_map supposes this table is const and later in make_join_select this table is used for making&calculation const condition. As table record buffer is not populated it leads to crash. The fix is adding a check if an engine supports HA_STATS_RECORDS_IS_EXACT flag before updating join->const_table_map. mysql-test/r/merge.result: test result mysql-test/t/merge.test: test case sql/sql_select.cc: adding a check if an engine supports HA_STATS_RECORDS_IS_EXACT flag before updating join->const_table_map.
-
- 14 Mar, 2010 1 commit
-
-
Staale Smedseng authored
SunStudio SunStudio compilers of late warn about methods that might hide methods in base classes due to the use of overloading combined with overriding. SunStudio also warns about variables defined in local socpe or method arguments that have the same name as a member attribute of the class. This patch renames methods that might hide base class methods, to make it easier both for humans and compilers to see what is actually called. It also renames variables in local scope. sql/field.cc: Local scope variable or method argument same as class attribute. sql/item_cmpfunc.cc: Local scope variable or method argument same as class attribute. sql/item_create.cc: Renaming base class create() to create_func(). sql/item_create.h: Renaming base class create() to create_func(). sql/protocol.cc: Local scope variable or method argument same as class attribute. sql/sql_profile.cc: Local scope variable or method argument same as class attribute. sql/sql_select.cc: Local scope variable or method argument same as class attribute. sql/sql_yacc.yy: Renaming base class create() to create_func(). storage/federated/ha_federated.cc: Local scope variable or method argument same as class attribute. storage/myisammrg/ha_myisammrg.cc: Local scope variable or method argument same as class attribute.
-
- 09 Mar, 2010 1 commit
-
-
Davi Arnaut authored
The problem is that not all column names retrieved from a SELECT statement can be used as view column names due to length and format restrictions. The server failed to properly check the conformity of those automatically generated column names before storing the final view definition on disk. Since columns retrieved from a SELECT statement can be anything ranging from functions to constants values of any format and length, the solution is to rewrite to a pre-defined format any names that are not acceptable as a view column name. The name is rewritten to "Name_exp_%u" where %u translates to the position of the column. To avoid this conversion scheme, define explict names for the view columns via the column_list clause. Also, aliases are now only generated for top level statements. mysql-test/include/view_alias.inc: Add test case for Bug#40277 mysql-test/r/compare.result: Bug#40277: SHOW CREATE VIEW returns invalid SQL mysql-test/r/group_by.result: Bug#40277: SHOW CREATE VIEW returns invalid SQL mysql-test/r/ps.result: Bug#40277: SHOW CREATE VIEW returns invalid SQL mysql-test/r/subselect.result: Bug#40277: SHOW CREATE VIEW returns invalid SQL mysql-test/r/subselect3.result: Bug#40277: SHOW CREATE VIEW returns invalid SQL mysql-test/r/type_datetime.result: Bug#40277: SHOW CREATE VIEW returns invalid SQL mysql-test/r/union.result: Bug#40277: SHOW CREATE VIEW returns invalid SQL mysql-test/r/view.result: Add test case result for Bug#40277 mysql-test/r/view_alias.result: Add test case result for Bug#40277 mysql-test/t/view_alias.test: Add test case for Bug#40277 sql/sql_view.cc: Check if auto generated column names are conforming. Also, the make_unique_view_field_name function is not used as it uses the original name to construct a new one, which does not work if the name is invalid.
-
- 05 Mar, 2010 1 commit
-
-
Gleb Shchepa authored
consider clustered primary keys Choosing a shortest index for the covering index scan, the optimizer ignored the fact, that the clustered primary key read involves whole table data. The find_shortest_key function has been modified to take into account that fact that a clustered PK has a longest key of possible covering indices. mysql-test/r/innodb_mysql.result: Test case for bug #39653. mysql-test/t/innodb_mysql.test: Test case for bug #39653. sql/sql_select.cc: Bug #39653: find_shortest_key in sql_select.cc does not consider clustered primary keys The find_shortest_key function has been modified to take into account that fact that a clustered PK has a longest key of possible covering indices.
-
- 26 Feb, 2010 2 commits
-
-
Sergey Glukhov authored
The problem is that cond->fix_fields(thd, 0) breaks condition(cuts off 'having'). The reason of that is that NULL valued Item pointer is present in the middle of Item list and it breaks the Item processing loop. mysql-test/r/having.result: test case mysql-test/t/having.test: test case sql/item_cmpfunc.h: added ASSERT to make sure that we do not add NULL valued Item pointer sql/sql_select.cc: skip adding an item to condition if Item pointer is NULL. skip adding a list to condition if this list is empty.
-
Evgeny Potemkin authored
performance degradation. Filesort + join cache combination is preferred to full index scan because it is usually faster. But it's not the case when the index is clustered one. Now test_if_skip_sort_order function prefers filesort only if index isn't clustered. mysql-test/r/innodb_mysql.result: Added a test case for the bug#50843. mysql-test/t/innodb_mysql.test: Added a test case for the bug#50843. sql/sql_select.cc: Bug#50843: Filesort used instead of clustered index led to performance degradation. Now test_if_skip_sort_order function prefers filesort only if index isn't clustered.
-
- 25 Feb, 2010 1 commit
-
-
Alexey Kopytov authored
The problem was in an incorrect debug assertion. The expression used in the failing assertion states that when finding references matching ORDER BY expressions, there can be only one reference to a single table. But that does not make any sense, all test cases for this bug are valid examples with multiple identical WHERE expressions referencing the same table which are also present in the ORDER BY list. Fixed by removing the failing assertion. We also have to take care of the 'found' counter so that we count multiple references only once. We rely on this fact later in eq_ref_table(). mysql-test/r/join.result: Added a test case for bug #50335. mysql-test/t/join.test: Added a test case for bug #50335. sql/sql_select.cc: Removing the assertion in eq_ref_table() as it does not make any sense. We also have to take care of the 'found' counter so that we count multiple references only once. We rely on this fact later in eq_ref_table().
-
- 16 Feb, 2010 1 commit
-
-
Sergey Glukhov authored
The problem is that during temporary table creation uneven bits are not taken into account for hidden fields. It leads to incorrect calculation&allocation of null bytes size for table record. And if grouped value is null we set wrong bit for this value(see end_update()). Fixed by adding separate calculation of uneven bit for hidden fields. mysql-test/r/type_bit.result: test case mysql-test/t/type_bit.test: test case sql/sql_select.cc: added separate calculation of uneven bit for hidden fields
-
- 10 Feb, 2010 1 commit
-
-
Sergey Glukhov authored
The problem becomes apparent only if HAVE_purify is undefined. It related to the part of code placed in open_table_from_share() fuction where we initialize record buffer only if HAVE_purify is enabled. So in case of HAVE_purify=OFF record buffer is not initialized on open table stage. Next we read key, find NULL value and update appropriate null bit but do not update record buffer. After that the record is stored in the join cache(store_record_in_cache). For CHAR fields we strip trailing spaces and in our case this procedure uses uninitialized record buffer. The fix is to skip stripping space procedure in case of null values for CHAR fields(partially based on 6.0 JOIN_CACHE implementation). mysql-test/r/join.result: test case mysql-test/t/join.test: test case sql/field.cc: code updated according to new CACHE_FIELD struct sql/sql_select.cc: code updated according to new CACHE_FIELD struct sql/sql_select.h: CACHE_FIELD struct: added new fields: Field *field, uint type; removed fields: Field_blob *blob_field, bool strip;
-
- 09 Feb, 2010 1 commit
-
-
Sergey Vojtovich authored
Queries optimized with GROUP_MIN_MAX didn't cleanup KEYREAD optimization properly. As a result subsequent queries may return incomplete rows (fields are initialized to default values). mysql-test/r/group_min_max.result: A test case for BUG#49902. mysql-test/t/group_min_max.test: A test case for BUG#49902. sql/opt_range.cc: Refactor of KEYREAD optimization switch so that KEYREAD handler state is in sync with st_table::key_read flag. All SQL code is supposed to switch KEYREAD optimization via st_table::set_keyread(). sql/opt_sum.cc: Refactor of KEYREAD optimization switch so that KEYREAD handler state is in sync with st_table::key_read flag. All SQL code is supposed to switch KEYREAD optimization via st_table::set_keyread(). sql/sql_select.cc: Refactor of KEYREAD optimization switch so that KEYREAD handler state is in sync with st_table::key_read flag. All SQL code is supposed to switch KEYREAD optimization via st_table::set_keyread(). sql/sql_update.cc: Refactor of KEYREAD optimization switch so that KEYREAD handler state is in sync with st_table::key_read flag. All SQL code is supposed to switch KEYREAD optimization via st_table::set_keyread(). sql/table.cc: Refactor of KEYREAD optimization switch so that KEYREAD handler state is in sync with st_table::key_read flag. All SQL code is supposed to switch KEYREAD optimization via st_table::set_keyread(). sql/table.h: Refactor of KEYREAD optimization switch so that KEYREAD handler state is in sync with st_table::key_read flag. All SQL code is supposed to switch KEYREAD optimization via st_table::set_keyread().
-
- 06 Feb, 2010 1 commit
-
-
Gleb Shchepa authored
Grouping by a subquery in a query with a distinct aggregate function lead to a wrong result (wrong and unordered grouping values). There are two related problems: 1) The query like this: SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c FROM t1 GROUP BY aa returned wrong result, because the outer reference "t1.a" in the subquery was substituted with the Item_ref item. The Item_ref item obtains data from the result_field object that refreshes once after the end of each group. This data is not applicable to filesort since filesort() doesn't care about groups (and doesn't update result_field objects with copy_fields() and so on). Also that data is not applicable to group separation algorithm: end_send_group() checks every record with test_if_group_changed() that evaluates Item_ref items, but it refreshes those Item_ref-s only after the end of group, that is a vicious circle and the grouped column values in the output are shifted. Fix: if a) we grouping by a subquery and b) that subquery has outer references to FROM list of the grouping query, then we substitute these outer references with Item_direct_ref like references under aggregate functions: Item_direct_ref obtains data directly from the current record. 2) The query with a non-trivial grouping expression like: SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c FROM t1 GROUP BY aa+0 also returned wrong result, since JOIN::exec() substitutes references to top-level aliases in SELECT list with Item_copy caching items. Item_copy items have same refreshing policy as Item_ref items, so the whole groping expression with Item_copy inside returns wrong result in filesort() and end_send_group(). Fix: include aliased items into GROUP BY item tree instead of Item_ref references to them. mysql-test/r/group_by.result: Test case for bug #45640 mysql-test/t/group_by.test: Test case for bug #45640 sql/item.cc: Bug #45640: optimizer bug produces wrong results Item_field::fix_fields() has been modified to resolve aliases in GROUP BY item trees into aliased items instead of Item_ref items. sql/item.h: Bug #45640: optimizer bug produces wrong results - Item::find_item_processor() has been introduced. - Item_ref::walk() has been modified to apply processors to itself too (not only to referenced item). sql/mysql_priv.h: Bug #45640: optimizer bug produces wrong results fix_inner_refs() has been modified to accept group_list parameter. sql/sql_lex.cc: Bug #45640: optimizer bug produces wrong results Initialization of st_select_lex::group_fix_field has been added. sql/sql_lex.h: Bug #45640: optimizer bug produces wrong results The st_select_lex::group_fix_field field has been introduced to control alias resolution in Itef_fied::fix_fields. sql/sql_select.cc: Bug #45640: optimizer bug produces wrong results - The fix_inner_refs function has been modified to treat subquery outer references like outer fields under aggregate functions, if they are included in GROUP BY item tree. - The find_order_in_list function has been modified to fix Item_field alias fields included in the GROUP BY item trees in a special manner.
-
- 03 Feb, 2010 6 commits
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.26 > revision-id: joro@sun.com-20091109140946-07wao5od7l1vn4x1 > parent: joro@sun.com-20091110082141-ldr8p6s1joczve2j > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48458-5.0-bugteam > timestamp: Mon 2009-11-09 16:09:46 +0200 > message: > Bug #48458: simple query tries to allocate enormous amount of > memory > > The server was doing a bad class typecast causing setting of > wrong value for the maximum number of items in an internal > structure used in equality propagation. > Fixed by not doing the wrong typecast and asserting the type > of the Item where it should be done.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.19 > revision-id: kostja@sun.com-20091103165854-7di545xruez8w207 > parent: li-bing.song@sun.com-20091103090041-zj7nedx6ok5jgges > committer: Konstantin Osipov <kostja@sun.com> > branch nick: 5.0-41756 > timestamp: Tue 2009-11-03 19:58:54 +0300 > message: > A fix and a test case for > Bug#41756 "Strange error messages about locks from InnoDB". > > In JT_EQ_REF (join_read_key()) access method, > don't try to unlock rows in the handler, unless certain that > a) they were locked > b) they are not used. > > Unlocking of rows is done by the logic of the nested join loop, > and is unaware of the possible caching that the access method may > have. This could lead to double unlocking, when a row > was unlocked first after reading into the cache, and then > when taken from cache, as well as to unlocking of rows which > were actually used (but taken from cache). > > Delegate part of the unlocking logic to the access method, > and in JT_EQ_REF count how many times a record was actually > used in the join. Unlock it only if it's usage count is 0. > > Implemented review comments.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.4.1 > revision-id: alexey.kopytov@sun.com-20091030155453-0vlfwki805h9os62 > parent: joerg@mysql.com-20091016122941-rf6z0keqvmlgjfto > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com> > branch nick: my50-bug48131 > timestamp: Fri 2009-10-30 18:54:53 +0300 > message: > Bug #48131: crash group by with rollup, distinct, filesort, > with temporary tables > > There were two problems the test case from this bug was > triggering: > > 1. JOIN::rollup_init() was supposed to wrap all constant Items > into another object for queries with the WITH ROLLUP modifier > to ensure they are never considered as constants and therefore > are written into temporary tables if the optimizer chooses to > employ them for DISTINCT/GROUP BY handling. > > However, JOIN::rollup_init() was called before > make_join_statistics(), so Items corresponding to fields in > const tables could not be handled as intended, which was > causing all kinds of problems later in the query execution. In > particular, create_tmp_table() assumed all constant items > except "hidden" ones to be removed earlier by remove_const() > which led to improperly initialized Field objects for the > temporary table being created. This is what was causing crashes > and valgrind errors in storage engines. > > 2. Even when the above problem had been fixed, the query from > the test case produced incorrect results due to some > DISTINCT/GROUP BY optimizations being performed by the > optimizer that are inapplicable in the WITH ROLLUP case. > > Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations > when the WITH ROLLUP modifier is present, and splitting the > const-wrapping part of JOIN::rollup_init() into a separate > method which is now invoked after make_join_statistics() when > the const tables are already known.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.13 > revision-id: joro@sun.com-20091030131543-2b23fnqckgbzvete > parent: joro@sun.com-20091030094044-quadg0bwjy7cwqzw > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48291-5.0-bugteam > timestamp: Fri 2009-10-30 15:15:43 +0200 > message: > Bug #48291 : crash with row() operator,select into @var, and > subquery returning multiple rows > > Error handling was missing when handling subqueires in WHERE > and when assigning a SELECT result to a @variable. > This caused crash(es). > > Fixed by adding error handling code to both the WHERE > condition evaluation and to assignment to an @variable.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.12 > revision-id: joro@sun.com-20091030094044-quadg0bwjy7cwqzw > parent: joro@sun.com-20091029152429-ks55fhrp4lhknyij > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48293-5.0-bugteam > timestamp: Fri 2009-10-30 11:40:44 +0200 > message: > Bug #48293: crash with procedure analyse, view with > 10 columns, > having clause... > > The fix for bug 46184 was not very complete. It was not covering > views using temporary tables and multiple tables in a FROM clause. > Fixed by reverting the fix for 46184 and making a more general > check that is checking at the right execution stage and for all > of the non-supported cases. > Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden. > Updated the analyse.test and subselect.test accordingly.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2818.1.4 > revision-id: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c > parent: azundris@mysql.com-20091021033856-ydodp4q42o58e7ka > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: b47019-5.0-bugteam > timestamp: Wed 2009-10-21 14:04:08 +0500 > message: > Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, > line 138 when forcing a spatial index > > Problem: "Spatial indexes can be involved in the search > for queries that use a function such as MBRContains() > or MBRWithin() in the WHERE clause". > Using spatial indexes for JOINs with =, <=> etc. > predicates is incorrect. > > Fix: disable spatial indexes for such queries.
-