mariadb

Commit Graph

Author	SHA1	Message	Date
unknown	c98a054fde	MDEV-5153: Server crashes in Item_ref::fix_fields on 2nd execution of PS with LEFT JOIN and MERGE view or SELECT SQ 1. Transformation of row IN subquery made the same as single value. 2. replace_where_subcondition() made working on several layers of OR/AND because it called on expression before fix_fields().	12 years ago
timour@askmonty.org	883af99e7d	MDEV-5104 crash in Item_field::used_tables with broken order by Analysis: st_select_lex_unit::prepare() computes can_skip_order_by as TRUE. As a result join->prepare() gets called with order == NULL, and doesn't do name resolution for the inner ORDER clause. Due to this the prepare phase doesn't detect that the query references non-exiting function and field. Later join->optimize() calls update_used_tables() for a non-resolved Item_field, which understandably has no Field object. This call results in a crash. Solution: Resolve unnecessary ORDER BY clauses to detect if they reference non-exising objects. Then remove such clauses from the JOIN object.	12 years ago
Sergei Golubchik	e7c4e6d870	MDEV-5012 Server crashes in Item_ref::real_item on EXPLAIN with select subqueries or views, constant table, derived_merge+derived_with_keys revert incorrect change, merged from mysql-5.5	12 years ago
Sergey Glukhov	2ec9dcf6a1	Bug#16095534 CRASH: PREPARED STATEMENT CRASHES IN ITEM_BOOL_FUNC2::FIX_LENGTH_AND_DEC The problem happened due to broken left expression in Item_in_optimizer object. In case of the bug left expression is runtime created Item_outer_ref item which is deleted at the end of the statement and one of Item_in_optimizer arguments becomes bad when re-executed. The fix is to use real_item() instead of original left expression. Note: It feels a bit weird that after preparing, the field is directly part of the generated Item_func_eq, whereas in execution it is replaced with an Item_outer_ref wrapper object. sql/item_subselect.cc: use left_expr->real_item() instead of original left expression because left_expr can be runtime created Ref item which is deleted at the end of the statement. Thus one of 'substitution' arguments can be broken in case of PS.	13 years ago
unknown	599a1384af	Fix for MDEV-4144 Analysis: The reason for the inefficent plan was that Item_subselect::is_expensive() didn't detect the special case when a subquery was optimized, but had no join plan because it either has no table, or its tables have been optimized away, or the optimizer detected that the result set is empty. Solution: Identify the special cases above in the Item_subselect::is_expensive(), and consider such degenerate subqueries inexpensive.	13 years ago
Murthy Narkedimilli	fe85f54640	Bug 16395495 - OLD FSF ADDRESS IN GPL HEADER	13 years ago
Sergei Golubchik	495fd27c0e	MDEV-4284 Assertion `cmp_items[(uint)cmp_type]' fails in sql/item_cmpfunc.cc Flip the switch and create Item_cache based on the argument's cmp_type, not argument's result_type(). Fix subselect_engine to calculate cmp_type correctly sql/item_subselect.h: mdev:4284	13 years ago
Murthy Narkedimilli	053d7e775c	Updated/added copyright headers.	13 years ago
Roy Lyseng	96c373c51a	Bug#15972635: Incorrect results returned in 32 table join with HAVING The problem is a shift operation that is not 64-bit safe. The consequence is that used tables information for a join with 32 tables or more will be incorrect. Fixed by adding a type cast in Item_sum::update_used_tables(). Also used the opportunity to fix some other potential bugs by adding an explicit type-cast to an integer in a left-shift operation. Some of them were quite harmless, but was fixed in order to get the same signed-ness as the other operand of the operation it was used in. sql/item_cmpfunc.cc Adjusted signed-ness for some integers in left-shift. sql/item_subselect.cc Added type-cast to nesting_map (which is a 32/64 bit type, so potential bug for deeply nested queries). sql/item_sum.cc Added type-cast to nesting_map (32/64-bit type) and table_map (64-bit type). sql/opt_range.cc Added type-cast to ulonglong (which is a 64-bit type). sql/sql_base.cc Added type-cast to nesting_map (which is a 32/64-bit type). sql/sql_select.cc Added type-cast to nesting_map (32/64-bit type) and key_part_map (64-bit type). sql/strfunc.cc Changed type-cast from longlong to ulonglong, to preserve signed-ness.	13 years ago
unknown	974abc7ad8	MDEV-3812 This patch undoes the removal of enum store_key_result by the previous patch for mdev-3812.	13 years ago
unknown	97a1c53c81	MDEV-3812: Remove unneeded extra call to engine->exec() in Item_subselect::exec, remove enum store_key_result This task fixes an ineffeciency that is a remainder from MySQL 5.0/5.1. There, subqueries were optimized in a lazy manner, when executed for the first time. During this lazy optimization it may happen that the server finds a more efficient subquery engine, and substitute the current engine of the query being executed with the new engine. This required re-execution of the engine. MariaDB 5.3 pre-optimizes subqueries in almost all cases, and the engine is chosen in most cases, except when subquery materialization found that it must use partial matching. In this case, the current code was performing one extra re-execution although it was not needed at all. The patch performs the re-execution only if the engine was changed while executing. In addition the patch performs small cleanup by removing "enum store_key_result" because it is essentially a boolean, and the code that uses it already maps it to a boolean.	13 years ago
Annamalai Gurusami	378a7d1ef5	Bug #14036214 MYSQLD CRASHES WHEN EXECUTING UPDATE IN TRX WITH CONSISTENT SNAPSHOT OPTION A transaction is started with a consistent snapshot. After the transaction is started new indexes are added to the table. Now when we issue an update statement, the optimizer chooses an index. When the index scan is being initialized via ha_innobase::change_active_index(), InnoDB reports the error code HA_ERR_TABLE_DEF_CHANGED, with message stating that "insufficient history for index". This error message is propagated up to the SQL layer. But the my_error() api is never called. The statement level diagnostics area is not updated with the correct error status (it remains in Diagnostics_area::DA_EMPTY). Hence the following check in the Protocol::end_statement() fails. 516 case Diagnostics_area::DA_EMPTY: 517 default: 518 DBUG_ASSERT(0); 519 error= send_ok(thd->server_status, 0, 0, 0, NULL); 520 break; The fix is to backport the fix of bugs 14365043, 11761652 and 11746399. 14365043 PROTOCOL::END_STATEMENT(): ASSERTION `0' FAILED 11761652 HA_RND_INIT() RESULT CODE NOT CHECKED 11746399 RETURN VALUES OF HA_INDEX_INIT() AND INDEX_INIT() IGNORED rb://1227 approved by guilhem and mattiasj.	13 years ago
Michael Widenius	ea6a4eef3a	Fixed issues found by buildbot & valgrind: - Wrong thd uses in Item_subselect, could lead to crash - Inititalize uninitialized variable in new autoincrement handling code sql/handler.cc: More DBUG_PRINT sql/item_subselect.cc: Wrong thd uses in Item_subselect, could lead to crash storage/innobase/handler/ha_innodb.cc: Initialize variable needed by upper level. This only happens when auto-increment value wraps over. storage/xtradb/handler/ha_innodb.cc: Initialize variable needed by upper level. This only happens when auto-increment value wraps over.	13 years ago
unknown	792efd59bc	MDEV-521 fix. After pullout item during single row subselect transformation it should be fixed properly.	13 years ago
unknown	b917fb63a6	Fix bug lp:1009187, mdev-373, mysql bug#58628 Analysis: The queries in question use the [unique \| index]_subquery execution methods. These methods reuse the ref keys constructed by create_ref_for_key(). The way create_ref_for_key() works is that it doesn't store in ref.key_copy[] store_key elements that represent constants. In particular it doesn't store the store_key for NULL constants. The execution of [unique \| index]_subquery calls subselect_uniquesubquery_engine::copy_ref_key, which in addition to copy the left IN argument into a index lookup key, is supposed to detect if the left IN argument contains NULLs. Since the store_key for the NULL constant is not copied into the key array, the null is not detected, and execution erroneously proceeds as if it should look for a complete match. Solution: The solution (unlike MySQL) is to reuse already computed information about NULL presence. Item_in_optimizer::val_int already finds out if the left IN operand contains NULLs. The fix propagates this to the execution methods subselect_[unique \| index]subquery_engine::exec so it knows if there were NULL values independent of the presence of keys. In addition the patch siplifies copy_ref_key() and the logic that hanldes the case of NULLs in the left IN operand.	13 years ago
Michael Widenius	3a793b9d4d	Added new status variables: feature_dynamic_columns,feature_fulltext,feature_gis,feature_locale,feature_subquery,feature_timezone,feature_trigger,feature_xml Opened_views, Executed_triggers, Executed_events Added new process status 'updating status' as part of 'freeing items' mysql-test/r/features.result: Test of feature_xxx status variables mysql-test/r/mysqld--help.result: Removed duplicated 'language' variable. mysql-test/r/view.result: Test of opened_views mysql-test/suite/rpl/t/rpl_start_stop_slave.test: Write more information on failure mysql-test/t/features.test: Test of feature_xxx status variables mysql-test/t/view.test: Test of opened_views sql/event_scheduler.cc: Increment executed_events status variable sql/field.cc: Increment status variable sql/item_func.cc: Increment status variable sql/item_strfunc.cc: Increment status variable sql/item_subselect.cc: Increment status variable sql/item_xmlfunc.cc: Increment status variable sql/mysqld.cc: Add new status variables to 'show status' sql/mysqld.h: Added executed_events sql/sql_base.cc: Increment status variable sql/sql_class.h: Add new status variables sql/sql_parse.cc: Added new process status 'updating status' as part of 'freeing items' sql/sql_trigger.cc: Increment status variable sql/sys_vars.cc: Increment status variable sql/tztime.cc: Increment status variable	13 years ago
unknown	4d2b05b7d7	fix for MDEV-367 The problem was that was_null and null_value variables was reset in each reexecution of IN subquery, but engine rerun only for non-constant subqueries. Fixed checking constant in Item_equal sort. Fix constant reporting in Item_subselect.	13 years ago
Sergei Golubchik	8d69a0feaa	MDEV-472 mysql-test-run --valgrind main.ps_2myisam gives warning about not initialized memory Item::get_date() should return 1 unless the value is a valid date.	13 years ago
Michael Widenius	dd8bd2e4c3	Fixed compiler warnings sql/item_subselect.cc: Added purecov info sql/sql_select.cc: Added cast storage/innobase/handler/ha_innodb.cc: Added cast storage/xtradb/btr/btr0btr.c: Added buf_block_get_frame_fast() to avoid compiler warning storage/xtradb/handler/ha_innodb.cc: Added cast storage/xtradb/include/buf0buf.h: Innodb has buf_block_get_frame(block) defined as (block)->frame. Didn't want to do a big change to break xtradb as it may use block_get_frame() differently, so I mad this quick hack to patch one compiler warning.	13 years ago
Michael Widenius	b886cac712	Fixed compiler errors Updated test to also work on 32 bit mysql-test/suite/heap/heap.test: Updated test to also work on 32 bit	13 years ago
Sergey Glukhov	2f30b34095	Bug #14409015 MEMORY LEAK WHEN REFERENCING OUTER FIELD IN HAVING When resolving outer fields, Item_field::fix_outer_fields() creates new Item_refs for each execution of a prepared statement, so these must be allocated in the runtime memroot. The memroot switching before resolving JOIN::having causes these to be allocated in the statement root, leaking memory for each PS execution. sql/item_subselect.cc: addon, fix for 11829691, item could be created in runtime memroot, so we need to use real_item instead.	13 years ago
Sergey Petrunya	55597a4869	MDEV-410: EXPLAIN shows type=range, while SHOW EXPLAIN and userstat show full table scan is used - Make Item_subselect::fix_fields() ignore UNCACHEABLE_EXPLAIN flag when deciding whether the subquery item should be marked as constant.	13 years ago
unknown	db6dbadb5a	Fix bug lp:1008686 Analysis: The fix for bug lp:985667 implements the method Item_subselect::no_rows_in_result() for all main kinds of subqueries. The purpose of this method is to be called from return_zero_rows() and set Items to some default value in the case when a query returns no rows. Aggregates and subqueries require special treatment in this case. Every implementation of Item_subselect::no_rows_in_result() called Item_subselect::make_const() to set the subquery predicate to its default value irrespective of where the predicate was located in the query. Once the predicate was set to a constant it was never executed. At the same time, the JOIN object of the fake select for UNIONs (the one used for the final result of the UNION), was set after all subqueries in the union were executed. Since we set the subquery as constant, it was never executed, and the corresponding JOIN was never created. In order to decide whether the result of NOT IN is NULL or FALSE, Item_in_optimizer needs to check if the subquery result was empty or not. This is where we got the crash, because subselect_union_engine::no_rows() checks for unit->fake_select_lex->join->send_records, and the join object was NULL. Solution: If a subquery is in the HAVING clause it must be evaluated in order to know its result, so that we can properly filter the result records. Once subqueries in the HAVING clause are executed even in the case of no result rows, this specific crash will be solved, because the UNION will be executed, and its JOIN will be constructed. Therefore the fix for this crash is to narrow the fix for lp:985667, and to apply Item_subselect::no_rows_in_result() only when the subquery predicate is in the SELECT clause.	14 years ago
unknown	88d3d853f4	Fix bug lp:1008773 Analysis: Queries with implicit grouping (there is aggregate, but no group by) follow some non-obvious semantics in the case of empty result set. Aggregate functions produce some special "natural" value depending on the function. For instance MIN/MAX return NULL, COUNT returns 0. The complexity comes from non-aggregate expressions in the select list. If the non-aggregate expression is a constant, it can be computed, so we should return its value, however if the expression is non-constant, and depends on columns from the empty result set, then the only meaningful value is NULL. The cause of the wrong result was that for subqueries the optimizer didn't make a difference between constant and non-constant ones in the case of empty result for implicit grouping. Solution: In all implementations of Item_subselect::no_rows_in_result() check if the subquery predicate is constant. If it is constant, do not set it to the default value for implicit grouping, instead let it be evaluated.	14 years ago
unknown	02bdc608b5	Fix bug lp:1002079 Analysis: The optimizer detects an empty result through constant table optimization. Then it calls return_zero_rows(), which in turns calls inderctly Item_maxmin_subselect::no_rows_in_result(). The latter method set "value=0", however "value" is pointer to Item_cache, and not just an integer value. All of the Item_[maxmin \| singlerow]_subselect::val_XXX methods does: if (forced_const) return value->val_real(); which of course crashes when value is a NULL pointer. Solution: When the optimizer discovers an empty result set, set Item_singlerow_subselect::value to a FALSE constant Item instead of NULL.	14 years ago
unknown	da5214831d	Fix for bug lp:944706, task MDEV-193 The patch enables back constant subquery execution during query optimization after it was disabled during the development of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION). The main idea is that constant subqueries are allowed to be executed during optimization if their execution is not expensive. The approach is as follows: - Constant subqueries are recursively optimized in the beginning of JOIN::optimize of the outer query. This is done by the new method JOIN::optimize_constant_subqueries(). This is done so that the cost of executing these queries can be estimated. - Optimization of the outer query proceeds normally. During this phase the optimizer may request execution of non-expensive constant subqueries. Each place where the optimizer may potentially execute an expensive expression is guarded with the predicate Item::is_expensive(). - The implementation of Item_subselect::is_expensive has been extended to use the number of examined rows (estimated by the optimizer) as a way to determine whether the subquery is expensive or not. - The new system variable "expensive_subquery_limit" controls how many examined rows are considered to be not expensive. The default is 100. In addition, multiple changes were needed to make this solution work in the light of the changes made by MWL#89. These changes were needed to fix various crashes and wrong results, and legacy bugs discovered during development.	14 years ago
Sergei Golubchik	1a4633059e	implement Item_singlerow_subselect::get_date() to avoid unnecessary date->string->date conversion	14 years ago
Sergei Golubchik	beec2a2b1d	MDEV-241 lp:992722 - Server crashes in get_datetime_value Create an Item_cache based on item's cmp_type, not result_type in subselect_engine. Use result_field in Item_cache_temporal::cache_value(), just like all other Item_cache*::cache_value() do.	14 years ago
unknown	c04786d3e3	Fix bug lp:985667, MDEV-229 Analysis: The reason for the wrong result is the interaction between constant optimization (in this case 1-row table) and subquery optimization. - First the outer query is optimized, and 'make_join_statistics' finds that table t2 has one row, reads that row, and marks the whole table as constant. This also means that all fields of t2 are constant. - Next, we optimize the subquery in the end of the outer 'make_join_statistics'. The field 'f2' is considered constant, with value '3'. The subquery predicate is rewritten as the constant TRUE. - The outer query execution detects early that the whole query result is empty and calls 'return_zero_rows'. Since the query is with implicit grouping, we have to produce one row with special values for the aggregates (depending on each aggregate function), and NULL values for all non-aggregate fields. This function calls 'no_rows_in_result' to set each aggregate function to the default value when it aggregates over an empty result, and then calls 'send_data', which in turn evaluates each Item in the SELECT list. - When evaluation reaches the subquery predicate, it executes the subquery with field 'f2' having a constant value '3', and the subquery produces the incorrect result '7'. Solution: Implement Item::no_rows_in_result for all subquery predicates. In order to make this work, it is also needed to make all val_* methods of all subquery predicates respect the Item_subselect::forced_const flag. Otherwise subqueries are executed anyways, and override the default value set by no_rows_in_result with whatever result is produced from the subquery evaluation.	14 years ago
Sergey Petrunya	994c6db2d1	BUG#978479: Wrong result (extra rows) with derived_with_keys+loosescan+semijoin=ON, materialization=OFF Part#1: make EXPLAIN's plan match the one by actual execution: Item_subselect::used_tables() should return the same value irrespectively of whether we're running an EXPLAIN or a SELECT.	14 years ago
Igor Babaev	f081107fe0	Fixed LP bug #972943 properly. The previous patch for the bug (that erroneously identified the bug as bug 972973 in its comment) was incorrect. It turned out that the code that triggered the abort complain reported for the bug was not needed at all.	14 years ago
Igor Babaev	b95ae56b9f	Fixed LP bug #972973 . When the function free_tmp_table deletes the handler object for a temporary table the field TABLE::file for this table should be set to NULL. Otherwise an assertion failure may occur.	14 years ago
Sergey Petrunya	2a16e7674b	BUG#913030: Optimizer chooses a suboptimal excution plan for Q18 from DBT-3 - When doing join optimization, pre-sort the tables so that they mimic the execution order we've had with 'semijoin=off'. - That way, we will not get regressions when there are two query plans (the old and the new) that have indentical costs but different execution times (because of factors that the optimizer was not able to take into account).	14 years ago
Tor Didriksen	10120d363d	Backport of fix for Bug#12763207 - ASSERT IN SUBSELECT::SINGLE_VALUE_TRANSFORMER	14 years ago
Sergei Golubchik	d92009231d	a couple of minor post-5.5-merge cleanups include/mysql_com.h: remove "shutdown levels" that aren't shutdown levels from mysql_enum_shutdown_level mysys/my_addr_resolve.c: my_snprintf in 5.5 (but not in 5.3) supports %p sql/item_func.cc: use a method (that exists only in 5.5) instead of directly accessing a member sql/item_subselect.cc: use a method (that exists only in 5.5) instead of directly accessing a member sql/opt_subselect.cc: use a method (that exists only in 5.5) instead of directly accessing a member sql/sql_select.cc: use a method (that exists only in 5.5) instead of directly accessing a member	14 years ago
Sergey Petrunya	4ac230e557	Better comments	14 years ago
Ramil Kalimullin	30d32207e7	BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS A defect in the subquery substitution code may lead to a server crash: setting substitution's name should be followed by setting its length (to keep them in sync). mysql-test/r/gis.result: BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS test result. mysql-test/t/gis.test: BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS test case. sql/item_subselect.cc: BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS set substitution's name length as well as the name itself (to keep them in sync).	14 years ago
Igor Babaev	841a74a4d6	Fixed LP bug #939009 . The result of materialization of the right part of an IN subquery predicate is placed into a temporary table. Each row of the materialized table is distinct. A unique key over all fields of the temporary table is defined and created. It allows to perform key look-ups into the table. The table created for a materialized subquery can be accessed by key as any other table. The function best_access-path search for the best access to join a table to a given partial join. With some where conditions this function considers a possibility of a ref_or_null access. If such access employs the unique key on the temporary table then when estimating the cost this access the function tries to use the array rec_per_key. Yet, such array is not built for this unique key. This causes a crash of the server. Rows returned by the subquery that contain nulls don't have to be placed into temporary table, as they cannot be match any row produced by the left part of the subquery predicate. So all fields of the temporary table can be defined as non-nullable. In this case any ref_or_null access to the temporary table does not make any sense and it does not make sense to estimate such an access. The fix makes sure that the temporary table for a materialized IN subquery is defined with columns that are all non-nullable. The also ensures that any row with nulls returned by the subquery is not placed into the temporary table.	14 years ago
MySQL Build Team	7177a2b9d7	Updated/added copyright headers	14 years ago
unknown	5db8b5113b	Fixed creating limit for exists subquery.	14 years ago
Igor Babaev	bb4053afc3	Fixed LP bug #919427 . The function subselect_uniquesubquery_engine::copy_ref_key has to take into account that when EXPLAIN is processed the array of store_key object created for any TABLE_REF may contain elements for constant items. These items should be ignored by thefunction.	14 years ago
unknown	6b4c132bc7	Removed unused code merged from 5.2. In 5.3 we fix this problem by checking if we put max/min group function without GROUP BY artificially in case of MODE_ONLY_FULL_GROUP_BY sql mode.	14 years ago
Igor Babaev	cd55894a52	Fixed LP bug #910083 . The patch for bug 685411 erroneously removed a call of engine->set_thd() from Item_subselect::fix_fields().	14 years ago
Igor Babaev	6dfe0956d6	Back-ported the test cases for bug #12763207 from mysql-5.6 code line into 5.2 Completed the fix for this bug. Note: in 5.3 the affected 'if' statement in Item_in_subselect::single_value_transformer() starting with the condition (thd->variables.sql_mode & MODE_ONLY_FULL_GROUP_BY) should be removed altogether. The change from table.cc is not needed either. This is because in 5.3 - min/max transformation for subqueries are done at the optimization phase - evaluation of the expensive subqueries is done at the execution phase. Added an EXPLAIN EXTENDED to the test case for bug #12329653.	14 years ago
Igor Babaev	c9259f166b	Fixed LP bug #904345 . The MIN/MAX optimizer code from the function opt_sum_query erroneously did not take into account conjunctive conditions that did not depend on any table, yet were not identified as constant items. These could be items containing rand() or PS/SP parameters. These items are supposed to be evaluated at the execution phase. That's why if such conditions can be extracted from the WHERE condition the MIN/MAX optimization is not applied as currently it is always done at the optimization phase. (In 5.3 expensive subqueries are also evaluated only at the execution phase. So, if a constant condition with such subquery can be extracted from the WHERE clause the MIN/MAX optimization should not be applied in 5.3.) IF an IN/ALL/SOME predicate with a constant left part is transformed into an EXISTS subquery the resulting subquery should not be considered uncacheable if the right part of the predicate is not uncacheable. Backported the function dbug_print_item() from 5.3. The function is used only for debugging.	14 years ago
unknown	072073c09e	Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()	14 years ago
Sergey Petrunya	a1b4eadf89	BUG#868908: Crash in check_simple_equality() with semijoin + materialization + prepared statement - Part2: safety and code cleanup	14 years ago
Sergey Petrunya	8e25dcfcd7	BUG#868908: Crash in check_simple_equality() with semijoin + materialization + prepared statement - Part 1 of the fix: for semi-join merged subqueries, calling child_join->optimize() until we're done with all PS-lifetime optimizations in the parent.	14 years ago
unknown	5412e82c01	Fixed LP BUG#747278 The problem was that when we have single row subquery with no rows Item_cache(es) which represent result row was not null and being requested via element_index() returned random value. The fix is setting all Item_cache(es) in NULL before executing the query (reset() method) which guaranty NULL value of whole query or its elements requested in any way if no rows was found. set_null() method was added to Item_cache to guaranty correct NULL value in case of reseting the cache.	14 years ago
unknown	dc1b1d39a1	Fix bug lp:894326 The patch also fixes an unrelated compiler warning. Analysis: The temporary table created during SJ-materialization might be used for sorting for a group by operation. The sort buffers for this internal temporary table were not cleared by the execution code after each subquery re-execution. This resulted in a memory leak detected by valgrind. Solution: Cleanup the sort buffers for the semijon tables as well. sql/item_subselect.cc: - Fix a compiler warning and add logic to revert to table scan partial match when there are more rows in the materialized subquery than there can be bits in the NULL bitmap index used for partial matching. sql/opt_subselect.cc: - Fixed a memory leak detected by valgrind	14 years ago

1 2 3 4 5 ...

735 Commits (dfed447888e1ab71ec0c80b61459bde6ee6eaf66)