An error occurred fetching the project authors.
- 27 Jul, 2010 1 commit
-
-
Konstantin Osipov authored
Remove dead and unused code. Update to reflect the code review requests. include/thr_lock.h: Remove declarations for THR_LOCK_OWNER, added along with the patch for sensitive cursors. mysys/thr_lock.c: Remove support for multiple thr_lock requestors per THD. sql/lock.cc: Revert the patch that added support for sensitive cursors. sql/sp_rcontext.cc: Updated the use of mysql_open_cursor(). sql/sql_class.cc: Move the instance of Server_side_cursor from class Prepared_statement to class Statement. sql/sql_class.h: Move the isntance of Server_side_cursor from class Prepared_statement to class Statement. Remove multiple lock_ids of thr_lock. sql/sql_cursor.cc: Remove Sensitive_cursor implementation. sql/sql_cursor.h: Remove declarations for sensitive cursors. sql/sql_prepare.cc: Move the declaration of instance of Server_side_cursor from class Statement to class Prepared_statement, where it's used. sql/sql_select.cc: Remove sensitive cursor support. sql/sql_select.h: Remove sensitive cursor support. sql/sql_union.cc: Remove sensitive cursor support.
-
- 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.
-
- 08 Jul, 2010 1 commit
-
-
Davi Arnaut authored
Essentially, the problem is that safemalloc is excruciatingly slow as it checks all allocated blocks for overrun at each memory management primitive, yielding a almost exponential slowdown for the memory management functions (malloc, realloc, free). The overrun check basically consists of verifying some bytes of a block for certain magic keys, which catches some simple forms of overrun. Another minor problem is violation of aliasing rules and that its own internal list of blocks is prone to corruption. Another issue with safemalloc is rather the maintenance cost as the tool has a significant impact on the server code. Given the magnitude of memory debuggers available nowadays, especially those that are provided with the platform malloc implementation, maintenance of a in-house and largely obsolete memory debugger becomes a burden that is not worth the effort due to its slowness and lack of support for detecting more common forms of heap corruption. Since there are third-party tools that can provide the same functionality at a lower or comparable performance cost, the solution is to simply remove safemalloc. Third-party tools can provide the same functionality at a lower or comparable performance cost. The removal of safemalloc also allows a simplification of the malloc wrappers, removing quite a bit of kludge: redefinition of my_malloc, my_free and the removal of the unused second argument of my_free. Since free() always check whether the supplied pointer is null, redudant checks are also removed. Also, this patch adds unit testing for my_malloc and moves my_realloc implementation into the same file as the other memory allocation primitives. client/mysqldump.c: Pass my_free directly as its signature is compatible with the callback type -- which wasn't the case for free_table_ent.
-
- 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
-
- 25 Jun, 2010 1 commit
-
-
Gleb Shchepa authored
-
- 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.
-
- 23 Jun, 2010 1 commit
-
-
Tor Didriksen authored
Don't call member functions for a NIL pointer. mysql-test/r/subselect4.result: Add test case. mysql-test/t/subselect4.test: Add test case. sql/sql_select.cc: If the (virtual) member function clone_item() returns NULL, there is no substitution to be made, and we don't need to set the collation. The test was invoking Item_cache::clone_item()
-
- 22 Jun, 2010 1 commit
-
-
Gleb Shchepa authored
use limit efficiently Bug #36569: UPDATE ... WHERE ... ORDER BY... always does a filesort even if not required Also two bugs reported after QA review (before the commit of bugs above to public trees, no documentation needed): Bug #53737: Performance regressions after applying patch for bug 36569 Bug #53742: UPDATEs have no effect after applying patch for bug 36569 Execution of single-table UPDATE and DELETE statements did not use the same optimizer as was used in the compilation of SELECT statements. Instead, it had an optimizer of its own that did not take into account that you can omit sorting by retrieving rows using an index. Extra optimization has been added: when applicable, single-table UPDATE/DELETE statements use an existing index instead of filesort. A corresponding SELECT query would do the former. Also handling of the DESC ordering expression has been added when reverse index scan is applicable. From now on most single table UPDATE and DELETE statements show the same disk access patterns as the corresponding SELECT query. We verify this by comparing the result of SHOW STATUS LIKE 'Sort% Currently the get_index_for_order function a) checks quick select index (if any) for compatibility with the ORDER expression list or b) chooses the cheapest available compatible index, but only if the index scan is cheaper than filesort. Second way is implemented by the new test_if_cheaper_ordering function (extracted part the test_if_skip_sort_order()). mysql-test/r/log_state.result: Updated result for optimized query, bug #36569. mysql-test/r/single_delete_update.result: Test case for bug #30584, bug #36569 and bug #53742. mysql-test/r/update.result: Updated result for optimized query, bug #30584. Note: "Handler_read_last 1" omitted, see bug 52312: lost Handler_read_last status variable. mysql-test/t/single_delete_update.test: Test case for bug #30584, bug #36569 and bug #53742. sql/opt_range.cc: Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort even if not required * get_index_for_order() has been rewritten entirely and moved to sql_select.cc New QUICK_RANGE_SELECT::make_reverse method has been added. sql/opt_range.h: Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort even if not required * get_index_for_order() has been rewritten entirely and moved to sql_select.cc New functions: * QUICK_SELECT_I::make_reverse() * SQL_SELECT::set_quick() sql/records.cc: Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort even if not required * init_read_record_idx() has been modified to allow reverse index scan New functions: * rr_index_last() * rr_index_desc() sql/records.h: Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort even if not required init_read_record_idx() has been modified to allow reverse index scan sql/sql_delete.cc: Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort even if not required mysql_delete: an optimization has been added to skip unnecessary sorting with ORDER BY clause where select result ordering is acceptable. sql/sql_select.cc: Bug #30584, bug #36569, bug #53737, bug #53742: UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort even if not required The const_expression_in_where function has been modified to accept both Item and Field pointers. New functions: * get_index_for_order() * test_if_cheaper_ordering() has been extracted from test_if_skip_sort_order() to share with get_index_for_order() * simple_remove_const() sql/sql_select.h: Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort even if not required New functions: * test_if_cheaper_ordering() * simple_remove_const() * get_index_for_order() sql/sql_update.cc: Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort even if not required mysql_update: an optimization has been added to skip unnecessary sorting with ORDER BY clause where a select result ordering is acceptable. sql/table.cc: Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort even if not required New functions: * TABLE::update_const_key_parts() * is_simple_order() sql/table.h: Bug #30584, bug #36569: UPDATE/DELETE ... WHERE ... ORDER BY... always does a filesort even if not required New functions: * TABLE::update_const_key_parts() * is_simple_order()
-
- 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.
-
- 31 May, 2010 1 commit
-
-
Davi Arnaut authored
Fix various mismatches between function's language linkage. Any particular function that is declared in C++ but should be callable from C must have C linkage. Note that function types with different linkages are also distinct. Thus, if a function type is declared in C code, it will have C linkage (same if declared in a extern "C" block). client/mysql.cc: Mismatch between prototype and declaration. client/mysqltest.cc: mysqltest used to be C code. Use C linkage where appropriate. cmd-line-utils/readline/input.c: Isolate unreachable code. include/my_alloc.h: Function type must have C linkage. include/my_base.h: Function type must have C linkage. include/my_global.h: Add helper macros to avoid spurious namespace indentation. include/mysql.h.pp: Update ABI file. mysys/my_gethwaddr.c: Remove stray carriage return and fix coding style. plugin/semisync/semisync_master_plugin.cc: Callback function types have C linkage. plugin/semisync/semisync_slave_plugin.cc: Callback function types have C linkage. sql/derror.cc: Expected function type has C linkage. sql/field.cc: Use helper macro and fix indentation. sql/handler.cc: Expected function type has C linkage. sql/item_sum.cc: Correct function linkages. Remove now unnecessary cast. sql/item_sum.h: Add prototypes with the appropriate linkage as otherwise they are distinct. sql/mysqld.cc: Wrap functions in C linkage mode. sql/opt_range.cc: C language linkage is ignored for class member functions. sql/partition_info.cc: Add wrapper functions with C linkage for class member functions. sql/rpl_utility.h: Use helper macro and fix indentation. sql/sql_class.cc: Change type of thd argument -- THD is a class. Use helper macro and fix indentation. sql/sql_class.h: Change type of thd argument -- THD is a class. sql/sql_select.cc: Expected function type has C linkage. sql/sql_select.h: Move prototype to sql_test.h sql/sql_show.cc: Expected function type has C linkage. sql/sql_test.cc: Fix required function prototype and fix coding style. sql/sql_test.h: Removed unnecessary export and add another. storage/myisammrg/ha_myisammrg.cc: Expected function type has C linkage. storage/perfschema/pfs.cc: PSI headers are declared with C language linkage, which also applies to function types.
-
- 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.
-
- 28 Apr, 2010 1 commit
-
-
Konstantin Osipov authored
Fix for bug #46947 "Embedded SELECT without FOR UPDATE is causing a lock", with after-review fixes. SELECT statements with subqueries referencing InnoDB tables were acquiring shared locks on rows in these tables when they were executed in REPEATABLE-READ mode and with statement or mixed mode binary logging turned on. This was a regression which were introduced when fixing bug 39843. The problem was that for tables belonging to subqueries parser set TL_READ_DEFAULT as a lock type. In cases when statement/mixed binary logging at open_tables() time this type of lock was converted to TL_READ_NO_INSERT lock at open_tables() time and caused InnoDB engine to acquire shared locks on reads from these tables. Although in some cases such behavior was correct (e.g. for subqueries in DELETE) in case of SELECT it has caused unnecessary locking. This patch tries to solve this problem by rethinking our approach to how we handle locking for SELECT and subqueries. Now we always set TL_READ_DEFAULT lock type for all cases when we read data. When at open_tables() time this lock is interpreted as TL_READ_NO_INSERT or TL_READ depending on whether this statement as a whole or call to function which uses particular table should be written to the binary log or not (if yes then statement should be properly serialized with concurrent statements and stronger lock should be acquired). Test coverage is added for both InnoDB and MyISAM. This patch introduces an "incompatible" change in locking scheme for subqueries used in SELECT ... FOR UPDATE and SELECT .. IN SHARE MODE. In 4.1 the server would use a snapshot InnoDB read for subqueries in SELECT FOR UPDATE and SELECT .. IN SHARE MODE statements, regardless of whether the binary log is on or off. If the user required a different type of read (i.e. locking read), he/she could request so explicitly by providing FOR UPDATE/IN SHARE MODE clause for each individual subquery. On of the patches for 5.0 broke this behaviour (which was not documented or tested), and started to use locking reads fora all subqueries in SELECT ... FOR UPDATE/IN SHARE MODE. This patch restored 4.1 behaviour. mysql-test/include/check_concurrent_insert.inc: Added auxiliary script which allows to check if statement reading table allows concurrent inserts in it. mysql-test/include/check_no_concurrent_insert.inc: Added auxiliary script which allows to check that statement reading table doesn't allow concurrent inserts in it. mysql-test/include/check_no_row_lock.inc: Added auxiliary script which allows to check if statement reading table doesn't take locks on its rows. mysql-test/include/check_shared_row_lock.inc: Added auxiliary script which allows to check if statement reading table takes shared locks on some of its rows. mysql-test/r/bug39022.result: After bug #46947 'Embedded SELECT without FOR UPDATE is causing a lock' was fixed test case for bug 39022 has to be adjusted in order to trigger execution path on which original problem was encountered. mysql-test/r/innodb_mysql_lock2.result: Added coverage for handling of locking in various cases when we read data from InnoDB tables (includes test case for bug #46947 'Embedded SELECT without FOR UPDATE is causing a lock'). mysql-test/r/lock_sync.result: Added coverage for handling of locking in various cases when we read data from MyISAM tables. mysql-test/t/bug39022.test: After bug #46947 'Embedded SELECT without FOR UPDATE is causing a lock' was fixed test case for bug 39022 has to be adjusted in order to trigger execution path on which original problem was encountered. mysql-test/t/innodb_mysql_lock2.test: Added coverage for handling of locking in various cases when we read data from InnoDB tables (includes test case for bug #46947 'Embedded SELECT without FOR UPDATE is causing a lock'). mysql-test/t/lock_sync.test: Added coverage for handling of locking in various cases when we read data from MyISAM tables. sql/log_event.cc: Since LEX::lock_option member was removed we no longer can rely on its value in Load_log_event::print_query() to determine that log event correponds to LOAD DATA CONCURRENT statement (this was not correct in all situations anyway). A new Load_log_event's member was introduced as a replacement. It is initialized at event object construction time and explicitly indicates whether LOAD DATA was concurrent. sql/log_event.h: Since LEX::lock_option member was removed we no longer can rely on its value in Load_log_event::print_query() to determine that log event correponds to LOAD DATA CONCURRENT statement (this was not correct in all situations anyway). A new Load_log_event's member was introduced as a replacement. It is initialized at event object construction time and explicitly indicates whether LOAD DATA was concurrent. sql/sp_head.cc: sp_head::reset_lex(): Before parsing substatement reset part of parser state which needs this (e.g. set Yacc_state::m_lock_type to default value). sql/sql_acl.cc: Since LEX::reset_n_backup_query_tables_list() now also resets LEX::sql_command member (as it became part of Query_tables_list class) we have to restore it in cases when while working with proxy Query_table_list we assume that LEX::sql_command still corresponds to original SQL command being executed (for example, when we are logging statement to the binary log while having Query_tables_list reset and backed up). sql/sql_base.cc: Changed read_lock_type_for_table() to return a weak TL_READ type of lock in cases when we are executing statement which won't update tables directly and table doesn't belong to statement's prelocking list and thus can't be used by a stored function. It is OK to do so since in this case table won't be used by statement or function call which will be written to the binary log, so serializability requirements for it can be relaxed. One of results from this change is that SELECTs on InnoDB tables no longer takes shared row locks for tables which are used in subqueries (i.e. bug #46947 is fixed). Another result is that for similar SELECTs on MyISAM tables concurrent inserts are allowed. In order to implement this change signature of read_lock_type_for_table() function was changed to take pointers to Query_tables_list and TABLE_LIST objects. sql/sql_base.h: - Function read_lock_type_for_table() now takes pointers to Query_tables_list and TABLE_LIST elements as its arguments since to correctly determine lock type it needs to know what statement is being performed and whether table element for which lock type to be determined belongs to prelocking list. sql/sql_lex.cc: - Removed LEX::lock_option and st_select_lex::lock_option members. Places in parser that were using them now use Yacc_state::m_lock_type instead. - To emphasize that LEX::sql_command member is used during process of opening and locking of tables it was moved to Query_tables_list class. It is now reset by Query_tables_list::reset_query_tables_list() method. sql/sql_lex.h: - Removed st_select_lex::lock_option member as there is no real need for per-SELECT lock type (HIGH_PRIORITY option should apply to the whole statement. FOR UPDATE/LOCK IN SHARE MODE clauses can be handled without this member). The main effect which was achieved by introduction of this member, i.e. using TL_READ_DEFAULT lock type for subqueries, is now achieved by setting LEX::lock_option (or rather its replacement - Yacc_state::m_lock_type) to TL_READ_DEFAULT in almost all cases. - To emphasize that LEX::sql_command member is used during process of opening and locking of tables it was moved to Query_tables_list class. - Replaced LEX::lock_option with Yacc_state::m_lock_type in order to emphasize that this value is relevant only during parsing. Unlike for LEX::lock_option the default value for Yacc_state::m_lock_type is TL_READ_DEFAULT. Note that for cases when it is OK to take a "weak" read lock (e.g. simple SELECT) this lock type will be converted to TL_READ at open_tables() time. So this change won't cause negative change in behavior for such statements. OTOH this change ensures that, for example, for SELECTs which are used in stored functions TL_READ_NO_INSERT lock is taken when necessary and as result calls to such stored functions can be written to the binary log with correct serialization. sql/sql_load.cc: Load_log_event constructor now requires a parameter that indicates whether LOAD DATA is concurrent. sql/sql_parse.cc: LEX::lock_option was replaced with Yacc_state::m_lock_type. And instead of resetting the latter implicitly in mysql_init_multi_delete() we do it explicitly in the places in parser which call this function. sql/sql_priv.h: - To be able more easily distinguish high-priority SELECTs in st_select_lex::print() method added flag for HIGH_PRIORITY option. sql/sql_select.cc: Changed code not to rely on LEX::lock_option to determine that it is high-priority SELECT. It was replaced with Yacc_state::m_lock_type which is accessible only at parse time. So instead of LEX::lock_option we now rely on a newly introduced flag for st_select_lex::options - SELECT_HIGH_PRIORITY. sql/sql_show.cc: Since LEX::reset_n_backup_query_tables_list() now also resets LEX::sql_command member (as it became part of Query_tables_list class) we have to restore it in cases when while working with proxy Query_table_list we assume that LEX::sql_command still corresponds to original SQL command being executed. sql/sql_table.cc: Since LEX::reset_query_tables_list() now also resets LEX::sql_command member (as it became part of Query_tables_list class) we have to restore value of this member when this method is called by mysql_admin_table(), to make this code safe for re-execution. sql/sql_trigger.cc: Since LEX::reset_n_backup_query_tables_list() now also resets LEX::sql_command member (as it became part of Query_tables_list class) we have to restore it in cases when while working with proxy Query_table_list we assume that LEX::sql_command still corresponds to original SQL command being executed (for example, when we are logging statement to the binary log while having Query_tables_list reset and backed up). sql/sql_update.cc: Function read_lock_type_for_table() now takes pointers to Query_tables_list and TABLE_LIST elements as its arguments since to correctly determine lock type it needs to know what statement is being performed and whether table element for which lock type to be determined belongs to prelocking list. sql/sql_yacc.yy: - Removed st_select_lex::lock_option member as there is no real need for per-SELECT lock type (HIGH_PRIORITY option should apply to the whole statement. FOR UPDATE/LOCK IN SHARE MODE clauses can be handled without this member). The main effect which was achieved by introduction of this member, i.e. using TL_READ_DEFAULT lock type for subqueries, is now achieved by setting LEX::lock_option (or rather its replacement - Yacc_state::m_lock_type) to TL_READ_DEFAULT in almost all cases. - Replaced LEX::lock_option with Yacc_state::m_lock_type in order to emphasize that this value is relevant only during parsing. Unlike for LEX::lock_option the default value for Yacc_state::m_lock_type is TL_READ_DEFAULT. Note that for cases when it is OK to take a "weak" read lock (e.g. simple SELECT) this lock type will be converted to TL_READ at open_tables() time. So this change won't cause negative change in behavior for such statements. OTOH this change ensures that, for example, for SELECTs which are used in stored functions TL_READ_NO_INSERT lock is taken when necessary and as result calls to such stored functions can be written to the binary log with correct serialization. - To be able more easily distinguish high-priority SELECTs in st_select_lex::print() method we now use new flag in st_select_lex::options bit-field.
-
- 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.
-
- 13 Apr, 2010 1 commit
-
-
unknown authored
Problem: Segmentation fault in add_group_and_distinct_keys() when accessing field of what is assumed to be an Item_field object. Cause: In case of views, the item added to list by is_indexed_agg_distinct() was not of type Item_field, but Item_ref. Resolution: Add the real Item_field object, the one referred to by Item_ref object, to the list, instead. mysql-test/r/count_distinct.result: Results for test case for Bug#51980. mysql-test/t/count_distinct.test: Test case for Bug#51980. Table needs to contain at least two rows to avoid const table optimization. sql/sql_select.cc: Make sure it is the actual Item_field object that is pushed to the out_args list of is_indexed_agg_distinct(), and not Item_ref objects.
-
- 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.
-
- 31 Mar, 2010 1 commit
-
-
Mats Kindahl authored
This patch: - Moves all definitions from the mysql_priv.h file into header files for the component where the variable is defined - Creates header files if the component lacks one - Eliminates all include directives from mysql_priv.h - Eliminates all circular include cycles - Rename time.cc to sql_time.cc - Rename mysql_priv.h to sql_priv.h
-
- 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().
-
- 23 Feb, 2010 1 commit
-
-
Vladislav Vaintroub authored
It appears that stack overflow checks for recusrive stored procedure calls, that run in the normal server, did not work in embedded and were dummified with preprocessor magic( #ifndef EMBEDDED_SERVER ). The fix is to remove ifdefs, there is no reason not to run overflow checks and crash in deeply recursive calls. Note: Start of the stack (thd->thread_stack variable) in embedded is not necessarily exact but stil provides the best guess. Unless the caller of mysql_read_connect() is already deep in the stack, thd->thread_stack variable should approximate stack start address well.
-
- 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
-
- 12 Feb, 2010 1 commit
-
-
Evgeny Potemkin authored
function with distinct. Loose index scan is used to find MIN/MAX values using appropriate index and thus allow to avoid grouping. For each found row it updates non-aggregated fields with values from row with found MIN/MAX value. Without loose index scan non-aggregated fields are copied by end_send_group function. With loose index scan there is no need in end_send_group and end_send is used instead. Non-aggregated fields still need to be copied and this was wrongly implemented in QUICK_GROUP_MIN_MAX_SELECT::get_next. WL#3220 added a case when loose index scan can be used with end_send_group to optimize calculation of aggregate functions with distinct. In this case the row found by QUICK_GROUP_MIN_MAX_SELECT::get_next might belong to a next group and copying it will produce wrong result. Update of non-aggregated fields is moved to the end_send function from QUICK_GROUP_MIN_MAX_SELECT::get_next. mysql-test/r/group_min_max.result: Added a test case for the bug#50539. mysql-test/t/group_min_max.test: Added a test case for the bug#50539. sql/opt_range.cc: Bug#50539: Wrong result when loose index scan is used for an aggregate function with distinct. Update of non-aggregated fields is moved to the end_send function from QUICK_GROUP_MIN_MAX_SELECT::get_next. sql/sql_select.cc: Bug#50539: Wrong result when loose index scan is used for an aggregate function with distinct. Update of non-aggregated fields is moved to the end_send function from QUICK_GROUP_MIN_MAX_SELECT::get_next.
-
- 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().
-