mariadb

Commit Graph

Author	SHA1	Message	Date
Sergey Petrunya	34b6f51dab	MDEV-5582: Plugin 'MEMORY' has ref_count=1 after shutdown with materialization+semijoin - Let cleanup_empty_jtbm_semi_joins() walk into semi-join nests.	12 years ago
Igor Babaev	5b441013e1	Fixed bug mdev-5468. The field JOIN::select_lex->where should be updated after the call of remove_eq_conds() in the function make_join_statistics(). This matters for subselects.	12 years ago
Sergey Petrunya	669c6620af	[Backport to 5.3] MDEV-5337: Wrong result in mariadb 5.5.32 with ORDER BY + LIMIT when index_condition_pushdown=on - in test_if_skip_sort_order(), correct the condition under which we have the code that restores the previously pushed index condition.	12 years ago
unknown	5f5f7befe3	MDEV-5356: Server crashes in Item_equal::contains on 2nd execution of a PS THD::thd->activate_stmt_arena_if_needed() should be used to temporary activating statement arena instead of direct usage of THD::set_n_backup_active_arena() because possible such scenario: 1) func1 saves current arena and activates copy1 of statement arena 2) func2 saves copy1 of statement arena setup by func1 and activates copy2 3) some changes made for copy 2 4) func2 stores changed copy2 back to statenet arena and activates copy1 5) func1 store unchanged copy1 back to statemnt arena (rewrite changed copy 2 so changes become lost) and activates arena which was before.	12 years ago
unknown	3aa370bb69	MDEV-5515: 2nd execution of a prepared statement returns wrong results update_used_tables() should be called after handling derived tables in any case.	12 years ago
Igor Babaev	fde2777b27	Another attempt to fix the memory leak of mdev-5400.	12 years ago
Igor Babaev	d5262a63fc	Fixed bug mdev-5400: a memory leak in save_index() first seen in the test case for mdev-5382.	12 years ago
Igor Babaev	998ed51497	Made sure that JOIN::cond_equal is correctly set after the call of remove_eq_conds() in the function make_join_statistics().	12 years ago
Igor Babaev	c0f31dc9f3	Another attempt to fix bug mdev-5103. The earlier pushed fix for the bug was incomplete. It did not remove the main cause of the problem: the function remove_eq_conds() removed always true multiple equalities from any conjunct, but did not adjust the list of them stored in Item_cond_and::cond_equal.current_level. Simplified the test case for the bug and moved it to another test file. The fix triggered changes in EXPLAIN EXTENDED for some queries.	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
unknown	3cc3bcfcc5	MDEV-5107:Left Join Yields All Nulls Instead of Appropriate Matches MDEV-5034:Wrong result on LEFT JOIN with a SELECT SQ or a merge view, UNION in IN subquery Make reset null_row same as it was set in evaluate_null_complemented_join_record(). The problem was that view firlds detect null_row by not-yet-reset table.	12 years ago
Igor Babaev	81623bdc35	Fixed bug mdev-5135. The patch for bug mdev-5105 incorrectly counted conditions in nested joins.	12 years ago
Igor Babaev	7c87385e30	Fixed bug mdev-5105. The bug caused a memory overwrite in the function update_ref_and_keys() It happened due to a wrong value of SELECT_LEX::cond_count. This value historically was calculated by the fix_fields method. Now the logic of calling this method became too complicated and, as a result, this value is calculated not always correctly. The patch changes the way how and when the values of SELECT_LEX::cond_count and of SELECT_LEX::between_count are calculated. The new code does it just at the beginning of update_ref_and_keys().	12 years ago
Igor Babaev	00816a964f	Fixed bug mdev-5028. Apparently in a general case a short-cut for the distinct optimization is invalid if join buffers are used to join tables after the tables whose values are to selected.	12 years ago
unknown	ec7da1561e	MDEV-5039: incorrect Item_func_regex::update_used_tables() Other fix of maybe_null problem and revert of revno: 3608 "MDEV-3873 & MDEV-3876 & MDEV-3912 : Wrong result (extra rows) with ALL subquery from a MERGE view."	12 years ago
Igor Babaev	996f6194c6	Fixed bug mdev-5015. The patch for mdev-4355 had a defect: the cached values for bitmaps of used tables were not updated when processing degenerate OR formulas.	12 years ago
Sergey Petrunya	7e4845beea	MDEV-5011: ERROR Plugin 'MEMORY' has ref_count=1 after shutdown for SJM queries - Provide a special execution path for cleanup of degenerate non-merged semi-join children of degenerate selects.	12 years ago
Igor Babaev	02338228dd	Fixed bug mdev-4996. The fix for bug mdev-4971 not always correctly set the pointers to inherited multiple equalities in objects of the Item_equal class.	12 years ago
Igor Babaev	576a2b1533	Fixed bug mdev-4971. The function propagate_new_equalities() did not updated properly the references to inherited multiple equalities.	12 years ago
Igor Babaev	37f18d2318	Fixed bug mdev-4962. When a non-nullable datetime field is used under an IS NULL predicate of the WHERE condition in a query with outer joins the remove_eq_conds function should check whether this field belongs to an inner table of any outer join that can be, in a general case, a nested outer join.	12 years ago
Igor Babaev	650d3266bb	Fixed bug mdev-4952 When in function remove_eq_conds() a sub-formula of the processed condition is replaced for another formula we should ensure that in the resulting formula AND/OR levels must alternate.	12 years ago
Igor Babaev	901737c978	Fixed bug mdev-4944. The patch to fix mdev-4418 turned out to be incorrect. At the substitution of single row tables in make_join_statistics() the used multiple equalities may change and references to the new multiple equalities must be updated. The function remove_eq_conds() takes care of it and it should be called right after the substitution of single row tables. Calling it after the call of make_join_statistics was a mistake.	12 years ago
Igor Babaev	dbc84ff96c	Fixed bug mdev-4942. Made sure that degenerate conjunctions/disjunctions are obtained from AND/OR conditions.	12 years ago
Igor Babaev	99992f6ec4	Fixed a bug/typo in the patch for mdev-4355, noticed after the patch had been merged into 5.5. Corrected the result of the output from the test case for mdev 4895.	12 years ago
Igor Babaev	008371b627	Backported from maria-5.5 the fix in the patch for mdev-4418 that had been discovered when merging the patch from 5.3 into 5.5.	12 years ago
Igor Babaev	25c152018d	Fixed bug mdev-4418. After single row substitutions there might appear new equalities. They should be properly propagated to all AND/OR levels the WHERE condition. It's done now with an additional call of remove_eq_conds().	12 years ago
Igor Babaev	fa7f677218	Fixed bug mdev-4355. This patch almost totally revised the patch for bug mdev-4177. The latter had too many defects. In particular, it did not propagate multiple equalities formed when merging a degenerate disjunct into underlying AND formula.	12 years ago
Igor Babaev	6dd9f049ab	Fixed bug mdev-4894. This a an old legacy performance bug. When a very selective range scan existed for the second table in a join, and, at the same time, there was another range condition depending on the fields of the first table, the optimizer chose a plan with 'Range checked for each record'. This plan was extremely inefficient in comparison with the regular selective range scan. As a matter of fact the range scan chosen for each record was the same as that selective range scan. Changed the test case for bug 24776 to preserve the old output for explain.	12 years ago
Sergei Golubchik	58fa29e0ff	MDEV-4610 SQL query crashes MariaDB with derived_with_keys MDEV-4643 MariaDB crashes consistently when trying a SELECT on VIEW with a UNION and an additional JOIN in SELECT open derived temp tables before trying QUICK_SELECT for them, handler::multi_range_read_info() needs an open table.	13 years ago
Michael Widenius	4e9bf37f1f	MDEV-4280: Assertion `empty_size == empty_size_on_page' failure in ma_blockrec.c or ER_NOT_KEYFILE on query with DISTINCT and GROUP BY This could happen when using Aria for internal temporary files (default case) and using DISTINCT. _ma_scan_restore_block_record() didn't work correctly if there was rows inserted, updated or deleted on the handler between calls to _ma_scan_remember_block_record() and _ma_scan_restore_block_record(). The effect was that some DISTINCT queries that used remove_dup_with_compare() could fail. .bzrignore: Ignore sql_yacc.hh mysql-test/suite/maria/r/distinct.result: Test case for MDEV-4280 mysql-test/suite/maria/t/distinct.test: Test case for MDEV-4280 mysql-test/t/mysql.test: Fixed test suite (we could get error -1 in some cases) sql/sql_select.cc: Break loop if restart_rnd_next() gives an error storage/maria/ha_maria.cc: scan_restore_pos() can return disk fault error. storage/maria/ma_blockrec.c: _ma_scan_remember_block_record() did incorrectly update scan.dir instead of scan_save.dir . _ma_scan_restore_block_record() didn't work correctly if there was rows inserted,updated or deleted on the handler between calls to _ma_scan_remember_block_record() and _ma_scan_restore_block_record(). Fixed by adding counters for row changes and reading the current scan page if changes had been made. storage/maria/ma_blockrec.h: scan_restore_pos() can return disk fault error. storage/maria/ma_delete.c: Increment row_changes storage/maria/ma_scan.c: scan_restore_pos() can return disk fault error. storage/maria/ma_update.c: Increment row_changes storage/maria/ma_write.c: Increment row_changes storage/maria/maria_def.h: scan_restore_pos() can return disk fault error.	13 years ago
Igor Babaev	920c479c6e	Fixed bug mdev-4336. When iterating over a list of conditions using List_iterator the function remove_eq_conds should skip all predicates that replace a condition from the list. Otherwise it can come to an infinite recursion.	13 years ago
Igor Babaev	b249680fd1	Made consistent handling of the predicates of the form <non-nullable datatime field> IS NULL in outer joins with that in inner joins. Previously such condition was transformed into the condition <non-nullable datatime field> = 0 unless the field belonged to an inner table of an outer join. In this case the predicate was interpreted as for any other field. Now if the field in the predicate <non-nullable datatime field> IS NULL belongs to an inner table of an outer join the predicate is transformed into the disjunction <non-nullable datatime field> = 0 OR <non-nullable datatime field> IS NULL. This is fully compatible with the semantics of such predicates in 5.5.	13 years ago
Igor Babaev	86f43c3077	Fixed bug mdev-4274. This bug was the result of incompleteness of the patch for bug mdev-4177. When an OR condition is simplified to a single conjunct it is merged into the embedding AND condition. Multiple equalities are also merged, and any field item involved in those equality should acquire a pointer to a the multiple equality formed by this merge.	13 years ago
Sergei Golubchik	6770a9a836	MDEV-4316 MariaDB server crash with signal 11 fulltext search was initialized for all MATCH ... AGAINST items at the end of the JOIN::optimize(). But since 5.3 derived tables are initialized lazily on first use, very late in the sub_select(). Skip Item_func_match::init_search initialization if the corresponding table isn't open yet; repeat fulltext initialization for all not-yet-initialized MATCH ... AGAINST items after creating derived tables.	13 years ago
Igor Babaev	21dad7ec30	Fixed bug mdev-4318. In some cases, when using views the optimizer incorrectly determined possible join orders for queries with nested outer and inner joins. This could lead to invalid execution plans for such queries.	13 years ago
unknown	2cd7cf8fe6	MDEV-4269 fix. Item_default_value inherited form Item_field so should create temporary table field similary.	13 years ago
Igor Babaev	926b0f54c9	Fixed bug mdev-4250. This is a bug in the legacy code. It did not manifest itself because it was masked by other bugs that were fixed by the patches for mdev-4172 and mdev-4177.	13 years ago
Igor Babaev	90c0f3d3ab	Fixed bug mdev-4209 Do not include BLOB fields into the key to access the temporary table created for a materialized view/derived table. BLOB components are not allowed in keys.	13 years ago
Igor Babaev	d434d79acf	Fixed bug mdev-4177 The function remove_eq_cond removes the parts of a disjunction for which it has been proved that they are always true. In the result of this removal the disjunction may be converted into a formula without OR that must be merged into the the AND formula that contains the disjunction. The merging of two AND conditions must take into account the multiple equalities that may be part of each of them. These multiple equality must be merged and become part of the and object built as the result of the merge of the AND conditions. Erroneously the function remove_eq_cond lacked the code that would merge multiple equalities of the merged AND conditions. This could lead to confusing situations when at the same AND level there were two multiple equalities with common members and the list of equal items contained only some of these multiple equalities. This, in its turn, could lead to an incorrect work of the function substitute_for_best_equal_field when it tried to optimize ref accesses. This resulted in forming invalid TABLE_REF objects that were used to build look-up keys when materialized subqueries were exploited.	13 years ago
Igor Babaev	ed7671d523	Fixed bug mdev-4172. This bug in the legacy code could manifest itself in queries with semi-join materialized subqueries. When a subquery is materialized all conditions that are imposed only on the columns belonging to the tables from the subquery are taken into account.The code responsible for subquery optimizations that employes subquery materialization makes sure to remove these conditions from the WHERE conditions of the query obtained after it has transformed the original query into a query with a semi-join. If the condition to be removed is an equality condition it could be added to ON expressions and/or conditions from disjunctive branches (parts of OR conditions) in an attempt to generate better access keys to the tables of the query. Such equalities are supposed to be removed later from all the formulas where they have been added to. However, erroneously, this was not done in some cases when an ON expression and/or a disjunctive part of the OR condition could be converted into one multiple equality. As a result some equality predicates over columns belonging to the tables of the materialized subquery remained in the ON condition and/or the a disjunctive part of the OR condition, and the excuter later, when trying to evaluate them, returned wrong answers as the values of the fields from these equalities were not valid. This happened because any standalone multiple equality (a multiple equality that are not ANDed with any other predicates) lacked the information about equality predicates inherited from upper levels (in particular, inherited from the WHERE condition). The fix adds a reference to such information to any standalone multiple equality.	13 years ago
Igor Babaev	c9b63e6a49	Fixed bug mdev-3913. The wrong result set returned by the left join query from the bug test case happened due to several inconsistencies and bugs of the legacy mysql code. The bug test case uses an execution plan that employs a scan of a materialized IN subquery from the WHERE condition. When materializing such an IN- subquery the optimizer injects additional equalities into the WHERE clause. These equalities express the constraints imposed by the subquery predicate. The injected equality of the query in the test case happens to belong to the same equality class, and a new equality imposing a condition on the rows of the materialized subquery is inferred from this class. Simultaneously the multiple equality is added to the ON expression of the LEFT JOIN used in the main query. The inferred equality of the form f1=f2 is taken into account when optimizing the scan of the rows the temporary table that is the result of the subquery materialization: only the values of the field f1 are read from the table into the record buffer. Meanwhile the inferred equality is removed from the WHERE conditions altogether as a constraint on the fields of the temporary table that has been used when filling this table. This equality is supposed to be removed from the ON expression when the multiple equalities of the ON expression are converted into an optimal set of equality predicates. It supposed to be removed from the ON expression as an equality inferred from only equalities of the WHERE condition. Yet, it did not happened due to the following bug in the code. Erroneously the code tried to build multiple equality for ON expression twice: the first time, when it called optimize_cond() for the WHERE condition, the second time, when it called this function for the HAVING condition. When executing optimize_con() for the WHERE condition a reference to the multiple equality of the WHERE condition is set in the multiple equality of the ON expression. This reference would allow later to convert multiple equalities of the ON expression into equality predicates. However the the second call of build_equal_items() for the ON expression that happened when optimize_cond() was called for the HAVING condition reset this reference to NULL. This bug fix blocks calling build_equal_items() for ON expressions for the second time. In general, it will be beneficial for many queries as it removes from ON expressions any equalities that are to be checked for the WHERE condition. The patch also fixes two bugs in the list manipulation operations and a bug in the function substitute_for_best_equal_field() that resulted in passing wrong reference to the multiple equalities of where conditions when processing multiple equalities of ON expressions. The code of substitute_for_best_equal_field() and the code the helper function eliminate_item_equal() were also streamlined and cleaned up. Now the conversion of the multiple equalities into an optimal set of equality predicates first produces the sequence of the all equalities processing multiple equalities one by one, and, only after this, it inserts the equalities at the beginning of the other conditions. The multiple changes in the output of EXPLAIN EXTENDED are mainly the result of this streamlining, but in some cases is the result of the removal of unneeded equalities from ON expressions. In some test cases this removal were reflected in the output of EXPLAIN resulted in disappearance of “Using where” in some rows of the execution plans.	13 years ago
Igor Babaev	48aee45957	Fixed bug mdev-3995. This bug happened because the executor tried to use a wrong TABLE REF object when building access keys. It constructed keys from fields of a materialized table from a ref object created to construct keys from the fields of the underlying base table. This could happen only when materialized table was created for a non-correlated IN subquery and only when the materialized table used for lookups. In this case we are guaranteed to be able to construct the keys from the fields of tables that would be outer tables for the tables of the IN subquery. The patch makes sure that no ref objects constructed from fields of materialized lookup tables are to be used.	13 years ago
Sergei Golubchik	0791692bdc	MDEV-3875 Wrong result (missing row) on a DISTINCT query with the same subquery in the SELECT list and GROUP BY fix remove_dup_with_hash_index() and remove_dup_with_compare() to take NULLs into account	13 years ago
unknown	a716b06167	MDEV-3988 fix. Subquery turned into constant too late to be excluded from grouping list so test for constant added to the create_temp_table().	13 years ago
Igor Babaev	12bf6fe858	Fixed bug mdev-4025. The bug could lead to a wrong estimate of the number of expected rows in the output of the EXPLAIN commands for queries with GROUP BY. This could be observed in the test case for LP bug 934348.	13 years ago
Igor Babaev	db1db8fa8c	Fixed LP bug #1002146 (bug mdev-645). If the setting of system variables does not allow to use join buffer for a join query with GROUP BY <f1,...> / ORDER BY <f1,...> then filesort is not needed if the first joined table is scanned in the order compatible with order specified by the list <f1,...>.	13 years ago
unknown	60a7b05871	MDEV-3801 Reproducible sub select join crash on 5.3.8 and 5.3.9 Properly drop all unused keys. Patch by Igor Babaev.	13 years ago
Igor Babaev	7714739b2d	Fixed bug mdev-585 (LP bug #637962 ) If, when executing a query with ORDER BY col LIMIT n, the optimizer chose an index-merge scan to access the table containing col while there existed an index defined over col then optimizer did not consider the possibility of using an alternative range scan by this index to avoid filesort. This could cause a performance degradation if the optimizer flag index_merge was set up to 'on'.	13 years ago
Neeraj Bisht	eef1a1957e	Bug#13726751 - 8 BYTE MEMORY LEAK IN DO_SAVE_BLOB Problem:- When we execute a query which has subquery with GROUP BY, ORDER BY and have a BLOB column,results a memory leak. Analysis:- In case of subquery, which have GROUP BY on BLOB and a ORDER BY on other field and BLOB is not a key. We allocate a tmp buffer to copy_field to take care of BLOB value.This copy_field value can have copies of its in two join(objects), so while freeing this copy_field we have to take care that it is not deleted twice. The double deletion of tmp_table_param.copy_field is handled by two patches. One by Kostja : revid:sp1r-konstantin@mysql.com-20050627101056-55153 Fix the broken test suite in -debug build. and other by Oleksandr revid:sp1r-bell@sanja.is.com.ua-20060118114857-19905 Excluded posibility of tmp_table_param.copy_field double deletion (BUG#14851). both of this patches are commited in different branch and while merging they both get placed,but there is no need for Kostja patch as Oleksandr patch handle this. sql/sql_select.cc: Bug13726751, tmp_join clean up is not necessary as later in the code we are taking care of cleaning up of tmp_join copy_field.	13 years ago
Sergey Petrunya	d2d6c8b8e8	Backport of: olav.sandstaa@oracle.com-20120516074923-vd0dhp183vqcp2ql .. into MariaDB 5.3 Fix for Bug#12667154 SAME QUERY EXEC AS WHERE SUBQ GIVES DIFFERENT RESULTS ON IN() & NOT IN() COMP #3 This bug causes a wrong result in mysql-trunk when ICP is used and bad performance in mysql-5.5 and mysql-trunk. Using the query from bug report to explain what happens and causes the wrong result from the query when ICP is enabled: 1. The t3 table contains four records. The outer query will read these and for each of these it will execute the subquery. 2. Before the first execution of the subquery it will be optimized. In this case the important is what happens to the first table t1: -make_join_select() will call the range optimizer which decides that t1 should be accessed using a range scan on the k1 index It creates a QUICK_RANGE_SELECT object for this. -As the last part of optimization the ICP code pushes the condition down to the storage engine for table t1 on the k1 index. This produces the following information in the explain for this table: 2 DEPENDENT SUBQUERY t1 range k1 k1 5 NULL 3 Using index condition; Using filesort Note the use of filesort. 3. The first execution of the subquery does (among other things) due to the need for sorting: a. Call create_sort_index() which again will call find_all_keys(): b. find_all_keys() will read the required keys for all qualifying rows from the storage engine. To do this it checks if it has a quick-select for the table. It will use the quick-select for reading records. In this case it will read four records from the storage engine (based on the range criteria). The storage engine will evaluate the pushed index condition for each record. c. At the end of create_sort_index() there is code that cleans up a lot of stuff on the join tab. One of the things that is cleaned is the select object. The result of this is that the quick-select object created in make_join_select is deleted. 4. The second execution of the subquery does the same as the first but the result is different: a. Call create_sort_index() which again will call find_all_keys() (same as for the first execution) b. find_all_keys() will read the keys from the storage engine. To do this it checks if it has a quick-select for the table. Now there is NO quick-select object(!) (since it was deleted in step 3c). So find_all_keys defaults to read the table using a table scan instead. So instead of reading the four relevant records in the range it reads the entire table (6 records). It then evaluates the table's condition (and here it goes wrong). Since the entire condition has been pushed down to the storage engine using ICP all 6 records qualify. (Note that the storage engine will not evaluate the pushed index condition in this case since it was pushed for the k1 index and now we do a table scan without any index being used). The result is that here we return six qualifying key values instead of four due to not evaluating the table's condition. c. As above. 5. The two last execution of the subquery will also produce wrong results for the same reason. Summary: The problem occurs due to all but the first executions of the subquery is done as a table scan without evaluating the table's condition (which is pushed to the storage engine on a different index). This is caused by the create_sort_index() function deleting the quick-select object that should have been used for executing the subquery as a range scan. Note that this bug in addition to causing wrong results also can result in bad performance due to executing the subquery using a table scan instead of a range scan. This is an issue in MySQL 5.5. The fix for this problem is to avoid that the Quick-select-object that the optimizer created is deleted when create_sort_index() is doing clean-up of the join-tab. This will ensure that the quick-select object and the corresponding pushed index condition will be available and used by all following executions of the subquery.	13 years ago

1 2 3 4 5 ...

3263 Commits (cfbc545d1aef20e7d47e0862d11e09c91f60ddeb)