mariadb

Commit Graph

Author	SHA1	Message	Date
Kristofer Pettersson	0a68603058	Bug#45613 handle failures from my_hash_insert Not all my_hash_insert() calls are checked for return value. This patch adds appropriate checks and failure responses where needed. mysys/hash.c: * Debug hook for testing failures in my_hash_insert()	16 years ago
Georgi Kodinov	a21cd97c35	Bug #45261 : Crash, stored procedure + decimal Bug #48370 Absolutely wrong calculations with GROUP BY and decimal fields when using IF Added the test cases in the above two bugs for regression testing. Added additional tests that demonstrate a incomplete fix. Added a new factory method for Field_new_decimal to create a field from an (decimal returning) Item. In the new method made sure that all the precision and length variables are capped in a proper way. This is required because Item's can have larger precision than the decimal fields and thus need to be capped when creating a field based on an Item type. Fixed the wrong typecast to Item_decimal.	16 years ago
Jorgen Loland	a120e969a8	Bug#48052: Valgrind warning - uninitialized value in init_read_record() - (records.cc:274) Item_cond::used_tables_cache was accessed in records.cc#init_read_record() without being initialized. It had not been initialized because it was wrongly assumed that the Item's variables would not be accessed, and hence quick_fix_field() was used instead of fix_fields() to save a few CPU cycles at creation time. The fix is to properly initilize the Item by replacing quick_fix_field() with fix_fields(). mysql-test/r/select.result: Add test for BUG#48052 mysql-test/t/select.test: Add test for BUG#48052 sql/sql_select.cc: Properly initialize Item_cond_and by calling fix_fields (instead of quick_fix_field) when the Item that "ANDs" WHERE clause conditions with HAVING clause conditions is created.	16 years ago
Alexey Kopytov	fb2e17903f	Fixed a gcc warning introduced by the patch for bug #48475 .	16 years ago
Georgi Kodinov	4519d5e4f1	Bug #48458 : simple query tries to allocate enormous amount of memory The server was doing a bad class typecast causing setting of wrong value for the maximum number of items in an internal structure used in equality propagation. Fixed by not doing the wrong typecast and asserting the type of the Item where it should be done.	16 years ago
Georgi Kodinov	ddd90017e7	Bug #42760 : Select doesn't return desired results when we have null values We should re-set the access method functions when changing the access method when switching to another index to avoid sorting. Fixed by doing a little re-engineering : encapsulating all the function assignment into a special function and calling it when flipping the indexes.	16 years ago
Alexey Kopytov	39f9a3ffd0	Bug #48475 : DISTINCT is ignored with GROUP BY WITH ROLLUP and only const tables The problem was caused by two shortcuts in the optimizer that are inapplicable in the ROLLUP case. Normally in a case when only const tables are involved in a query, DISTINCT clause can be safely optimized away since there may be only one row produced by the join. Similarly, we don't need to create a temporary table to resolve DISTINCT/GROUP BY/ORDER BY. Both of these are inapplicable when the WITH ROLLUP modifier is present. Fixed by disabling the said optimizations for the WITH ROLLUP case. mysql-test/r/olap.result: Added a test case for bug #48475. mysql-test/t/olap.test: Added a test case for bug #48475. sql/sql_select.cc: Disabled const-only table optimizations for the WITH ROLLUP case.	16 years ago
Konstantin Osipov	06c9d62a9f	A fix and a test case for Bug#41756 "Strange error messages about locks from InnoDB". In JT_EQ_REF (join_read_key()) access method, don't try to unlock rows in the handler, unless certain that a) they were locked b) they are not used. Unlocking of rows is done by the logic of the nested join loop, and is unaware of the possible caching that the access method may have. This could lead to double unlocking, when a row was unlocked first after reading into the cache, and then when taken from cache, as well as to unlocking of rows which were actually used (but taken from cache). Delegate part of the unlocking logic to the access method, and in JT_EQ_REF count how many times a record was actually used in the join. Unlock it only if it's usage count is 0. Implemented review comments. mysql-test/r/bug41756.result: Add result file (Bug#41756) mysql-test/t/bug41756-master.opt: Use --innodb-locks-unsafe-for-binlog, as in 5.0 just using read_committed isolation is not sufficient to reproduce the bug. mysql-test/t/bug41756.test: Add a test file (Bug#41756) sql/item_subselect.cc: Complete struct READ_RECORD initialization with a new member to unlock records. sql/records.cc: Extend READ_RECORD API with a method to unlock read records. sql/sql_select.cc: In JT_EQ_REF (join_read_key()) access method, don't try to unlock rows in the handler, unless certain that a) they were locked b) they are not used. sql/sql_select.h: Add members to TABLE_REF to count TABLE_REF buffer usage count. sql/structs.h: Update declarations.	16 years ago
Davi Arnaut	1ca80ed19e	Bug#48370: Absolutely wrong calculations with GROUP BY and decimal fields when using IF Bug#45261: Crash, stored procedure + decimal Revert fix for Bug#45261 due to unforeseen bugs.	16 years ago
Alexey Kopytov	b67cdaa351	Bug #48131 : crash group by with rollup, distinct, filesort, with temporary tables There were two problems the test case from this bug was triggering: 1. JOIN::rollup_init() was supposed to wrap all constant Items into another object for queries with the WITH ROLLUP modifier to ensure they are never considered as constants and therefore are written into temporary tables if the optimizer chooses to employ them for DISTINCT/GROUP BY handling. However, JOIN::rollup_init() was called before make_join_statistics(), so Items corresponding to fields in const tables could not be handled as intended, which was causing all kinds of problems later in the query execution. In particular, create_tmp_table() assumed all constant items except "hidden" ones to be removed earlier by remove_const() which led to improperly initialized Field objects for the temporary table being created. This is what was causing crashes and valgrind errors in storage engines. 2. Even when the above problem had been fixed, the query from the test case produced incorrect results due to some DISTINCT/GROUP BY optimizations being performed by the optimizer that are inapplicable in the WITH ROLLUP case. Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations when the WITH ROLLUP modifier is present, and splitting the const-wrapping part of JOIN::rollup_init() into a separate method which is now invoked after make_join_statistics() when the const tables are already known. mysql-test/r/olap.result: Added a test case for bug #48131. mysql-test/t/olap.test: Added a test case for bug #48131. sql/sql_select.cc: 1. Disabled inapplicable DISTINCT/GROUP BY optimizations when the WITH ROLLUP modifier is present. 2. Split the const-wrapping part of JOIN::rollup_init() into a separate method. sql/sql_select.h: Added rollup_process_const_fields() declaration.	16 years ago
Georgi Kodinov	9d96cd6dcb	Bug #48291 : crash with row() operator,select into @var , and subquery returning multiple rows Error handling was missing when handling subqueires in WHERE and when assigning a SELECT result to a @variable. This caused crash(es). Fixed by adding error handling code to both the WHERE condition evaluation and to assignment to an @variable.	16 years ago
Georgi Kodinov	851e250953	Bug #48293 : crash with procedure analyse, view with > 10 columns, having clause... The fix for bug 46184 was not very complete. It was not covering views using temporary tables and multiple tables in a FROM clause. Fixed by reverting the fix for 46184 and making a more general check that is checking at the right execution stage and for all of the non-supported cases. Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden. Updated the analyse.test and subselect.test accordingly.	16 years ago
Georgi Kodinov	ac37324843	Bug #42116 : Mysql crash on specific query Queries with nested outer joins may lead to crashes or bad results because an internal data structure is not handled correctly. The optimizer uses bitmaps of nested JOINs to determine if certain table can be placed at a certain place in the JOIN order. It does maintain a bitmap describing in which JOINs last placed table is nested. When it puts a table it makes sure the bit of every JOIN that contains the table in question is set (because JOINs can be nested). It does that by recursively setting the bit for the next enclosing JOIN when this is the first table in the JOIN and recursively resetting the bit if it's the last table in the JOIN. When it removes a table from the join order it should do the opposite : recursively unset the bit if it's the only remaining table in this join and and recursively set the bit if it's removing the last table of a JOIN. There was an error in how the bits was set for the upper levels : when removing a table it was setting the bit for all the enclosing nested JOINs even if there were more tables left in the current JOIN (which practically means that the upper nested JOINs were not affected). Fixed by stopping the recursion at the relevant level. mysql-test/r/join.result: Bug #42116: test case mysql-test/t/join.test: Bug #42116: test case sql/sql_select.cc: Bug #41116: don't go up and set the bits if more tables in at the current JOIN level	16 years ago
Ramil Kalimullin	17ed6b9abd	Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index Problem: "Spatial indexes can be involved in the search for queries that use a function such as MBRContains() or MBRWithin() in the WHERE clause". Using spatial indexes for JOINs with =, <=> etc. predicates is incorrect. Fix: disable spatial indexes for such queries. mysql-test/r/select.result: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - test result. mysql-test/t/select.test: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - test case. sql/sql_select.cc: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - disable spatial indexes for queries which use non-spatial conditions (e.g. NATURAL JOINs).	16 years ago
Jorgen Loland	bf14598c99	Followup patch for BUG#47280 Temporary tables may set join->group to 0 even though there is grouping. Also need to test if sum_func_count>0 when JOIN::exec() decides whether to present results in a grouped manner. sql/sql_select.cc: Temporary tables may set join->group to 0 even though there is grouping. Also need to test if sum_func_count>0 when JOIN::exec() decides whether to present results in a grouped manner.	16 years ago
Jorgen Loland	6da93b223b	Bug#47280 - strange results from count(*) with order by multiple columns without where/group Simple SELECT with implicit grouping used to return many rows if the query was ordered by the aggregated column in the SELECT list. This was incorrect because queries with implicit grouping should only return a single record. The problem was that when JOIN:exec() decided if execution needed to handle grouping, it was assumed that sum_func_count==0 meant that there were no aggregate functions in the query. This assumption was not correct in JOIN::exec() because the aggregate functions might have been optimized away during JOIN::optimize(). The reason why queries without ordering behaved correctly was that sum_func_count is only recalculated if the optimizer chooses to use temporary tables (which it does in the ordered case). Hence, non-ordered queries were correctly treated as grouped. The fix for this bug was to remove the assumption that sum_func_count==0 means that there is no need for grouping. This was done by introducing variable "bool implicit_grouping" in the JOIN object. mysql-test/r/func_group.result: Add test for BUG#47280 mysql-test/t/func_group.test: Add test for BUG#47280 sql/opt_sum.cc: Improve comment for opt_sum_query() sql/sql_class.h: Add comment for variables in TMP_TABLE_PARAM sql/sql_select.cc: Introduce and use variable implicit_grouping instead of (!group_list && sum_func_count) in places that need to test if grouping is required. Also added comments for: optimization of aggregate fields for implicitly grouped queries (JOIN::optimize) and choice of end_select method (JOIN::execute) sql/sql_select.h: Add variable implicit_grouping, which will be TRUE for queries that contain aggregate functions but no GROUP BY clause. Also added comment to sort_and_group variable.	16 years ago
Georgi Kodinov	1a48dd4e2b	Bug #43029 : FORCE INDEX FOR ORDER BY is ignored when join buffering is used FORCE INDEX FOR ORDER BY now prevents the optimizer from using join buffering. As a result the optimizer can use indexed access on the first table and doesn't need to sort the complete resultset at the end of the statement.	16 years ago
MySQL Build Team	dc7c927787	Backport into build-200909301147-5.0.84sp1 > ------------------------------------------------------------ > revno: 2791.2.3 > revision-id: joro@sun.com-20090827114042-h55n7qp9990bl6ge > parent: anurag.shekhar@sun.com-20090831073231-e55y1hsck6n08ux8 > committer: Georgi Kodinov <joro@sun.com> > branch nick: B46749-5.0-bugteam > timestamp: Thu 2009-08-27 14:40:42 +0300 > message: > Bug #46749: Segfault in add_key_fields() with outer subquery level > field references > > This error requires a combination of factors : > 1. An "impossible where" in the outermost SELECT > 2. An aggregate in the outermost SELECT > 3. A correlated subquery with a WHERE clause that includes an outer > field reference as a top level WHERE sargable predicate > > When JOIN::optimize detects an "impossible WHERE" it will bail out > without doing the rest of the work and initializations. It will not > call make_join_statistics() as well. And make_join_statistics fills > in various structures for each table referenced. > When processing the result of the "impossible WHERE" the query must > send a single row of data if there are aggregate functions in it. > In this case the server marks all the aggregates as having received > no rows and calls the relevant Item::val_xxx() method on the SELECT > list. However if this SELECT list happens to contain a correlated > subquery this subquery is evaluated in a normal evaluation mode. > And if this correlated subquery has a reference to a field from the > outermost "impossible where" SELECT the add_key_fields will mistakenly > consider the outer field reference as a "local" field reference when > looking for sargable predicates. > But since the SELECT where the outer field reference refers to is not > completely initialized due to the "impossible WHERE" in this level > we'll get a NULL pointer reference. > Fixed by making a better condition for discovering if a field is "local" > to the SELECT level being processed. > It's not enough to look for OUTER_REF_TABLE_BIT in this case since > for outer references to constant tables the Item_field::used_tables() > will return 0 regardless of whether the field reference is from the > local SELECT or not.	16 years ago
Sergey Glukhov	beb519e3ca	Bug#45989 memory leak after explain encounters an error in the query the fix is reverted from 5.1, mysql-pe as unnecessary(no valgrind warnings there). sql/sql_select.cc: the fix is reverted from 5.1, mysql-pe as unnecessary(no valgrind warnings there).	16 years ago
MySQL Build Team	152e207ddf	Backport into build-200909221805-5.1.37sp1 > ------------------------------------------------------------ > revno: 3092.1.2 [merge] > revision-id: joro@sun.com-20090831134035-wndnw04gy8kzogpm > parent: anurag.shekhar@sun.com-20090831075609-tkpqu41hxtupdeip > parent: joro@sun.com-20090827114042-h55n7qp9990bl6ge > committer: Georgi Kodinov <joro@sun.com> > branch nick: B46749-5.1-bugteam > timestamp: Mon 2009-08-31 16:40:35 +0300 > message: > automerge > ------------------------------------------------------------ > Use --include-merges or -n0 to see merged revisions.	16 years ago
MySQL Build Team	8ef621e1e8	Backport into build-200909221805-5.1.37sp1 > ------------------------------------------------------------ > revno: 3059 [merge] > revision-id: martin.hansson@sun.com-20090810140851-aw5peehzdxi4gjja > parent: iggy@mysql.com-20090806145453-ion37sfdsldwwjrj > parent: martin.hansson@sun.com-20090807115140-7fn6wjx0mrui7zl5 > committer: Martin Hansson <martin.hansson@sun.com> > branch nick: 5.1bt > timestamp: Mon 2009-08-10 16:08:51 +0200 > message: > Merge > ------------------------------------------------------------ > Use --include-merges or -n0 to see merged revisions.	16 years ago
Georgi Kodinov	5dda6c18cd	Bug #47106 : Crash / segfault on adding EXPLAIN to a non-crashing query The fix for bug 46749 removed the check for OUTER_REF_TABLE_BIT and substituted it for a check on the presence of Item_ident::depended_from. Removing it altogether was wrong : OUTER_REF_TABLE_BIT should still be checked in addition to depended_from (because it's not set in all cases and doesn't contradict to the check of depended_from). Fixed by returning the old condition back as a compliment to the new one.	16 years ago
Staale Smedseng	e5888b16af	Bug #43414 Parenthesis (and other) warnings compiling MySQL with gcc 4.3.2 This is the fifth patch cleaning up more GCC warnings about variables used before initialized using the new macro UNINIT_VAR().	16 years ago
Alexey Kopytov	505346028f	Bug #46159 : simple query that never returns The external 'for' loop in remove_dup_with_compare() handled HA_ERR_RECORD_DELETED by just starting over without advancing to the next record which caused an infinite loop. This condition could be triggered on certain data by a SELECT query containing DISTINCT, GROUP BY and HAVING clauses. Fixed remove_dup_with_compare() so that we always advance to the next record when receiving HA_ERR_RECORD_DELETED from rnd_next(). mysql-test/r/distinct.result: Added a test case for bug #46159. mysql-test/t/distinct.test: Added a test case for bug #46159. sql/sql_select.cc: Fixed remove_dup_with_compare() so that we always advance to the next record when receiving HA_ERR_RECORD_DELETED from rnd_next().	17 years ago
Sergey Glukhov	643fbe4234	Bug#45989 memory leak after explain encounters an error in the query Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up. The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy. mysql-test/r/explain.result: test result mysql-test/t/explain.test: test case sql/sql_select.cc: Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up. The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy.	17 years ago
Georgi Kodinov	629557ff13	Bug #46791 : Assertion failed:(table->key_read==0),function unknown function,file sql_base.cc When uncacheable queries are written to a temp table the optimizer must preserve the original JOIN structure, because it is re-using the JOIN structure to read from the resulting temporary table. This was done only for uncacheable sub-queries. But top level queries can also benefit from this mechanism, specially if they're using index access and need a reset. Fixed by not limiting the saving of JOIN structure to subqueries exclusively. Added a new test file to extend the existing (large) subquery.test.	17 years ago
Georgi Kodinov	a22c29d5e4	Bug #46749 : Segfault in add_key_fields() with outer subquery level field references This error requires a combination of factors : 1. An "impossible where" in the outermost SELECT 2. An aggregate in the outermost SELECT 3. A correlated subquery with a WHERE clause that includes an outer field reference as a top level WHERE sargable predicate When JOIN::optimize detects an "impossible WHERE" it will bail out without doing the rest of the work and initializations. It will not call make_join_statistics() as well. And make_join_statistics fills in various structures for each table referenced. When processing the result of the "impossible WHERE" the query must send a single row of data if there are aggregate functions in it. In this case the server marks all the aggregates as having received no rows and calls the relevant Item::val_xxx() method on the SELECT list. However if this SELECT list happens to contain a correlated subquery this subquery is evaluated in a normal evaluation mode. And if this correlated subquery has a reference to a field from the outermost "impossible where" SELECT the add_key_fields will mistakenly consider the outer field reference as a "local" field reference when looking for sargable predicates. But since the SELECT where the outer field reference refers to is not completely initialized due to the "impossible WHERE" in this level we'll get a NULL pointer reference. Fixed by making a better condition for discovering if a field is "local" to the SELECT level being processed. It's not enough to look for OUTER_REF_TABLE_BIT in this case since for outer references to constant tables the Item_field::used_tables() will return 0 regardless of whether the field reference is from the local SELECT or not.	17 years ago
Davi Arnaut	fc39459504	Bug#45261: Crash, stored procedure + decimal The problem was that creating a DECIMAL column from a decimal value could lead to a failed assertion as decimal values can have a higher precision than those attached to a table. The assert could be triggered by creating a table from a decimal with a large (> 30) scale. Also, there was a problem in calculating the number of digits in the integral and fractional parts if both exceeded the maximum number of digits permitted by the new decimal type. The solution is to ensure that truncation procedure is executed when deducing a DECIMAL column from a decimal value of higher precision. If the integer part is equal to or bigger than the maximum precision for the DECIMAL type (65), the integer part is truncated to fit and the fractional becomes zero. Otherwise, the fractional part is truncated to fit into the space left after the integer part is copied. This patch borrows code and ideas from Martin Hansson's patch. mysql-test/r/type_newdecimal.result: Add test case result for Bug#45261. Also, update test case to reflect that an additive operation increases the precision of the resulting type by 1. mysql-test/t/type_newdecimal.test: Add test case for Bug#45261 sql/field.cc: Added DBUG_ASSERT to ensure object's invariant is maintained. Implement method to create a field to hold a decimal value from an item. sql/field.h: Explain member variable. Add method to create a new decimal field. sql/item.cc: The precision should only be capped when storing the value on a table. Also, this makes it impossible to calculate the integer part if Item::decimals (the scale) is larger than the precision. sql/item.h: Simplify calculation of integer part. sql/item_cmpfunc.cc: Do not limit the precision. It will be capped later. sql/item_func.cc: Use new method for allocating a new decimal field. Add a specialized method for retrieving the precision of a user variable item. sql/item_func.h: Add method to return the precision of a user variable. sql/item_sum.cc: Use new method for allocating a new decimal field. sql/my_decimal.h: The integer part could be improperly calculated for a decimal with 31 digits in the fractional part. sql/sql_select.cc: Use new method which truncates the integer or decimal parts as needed.	17 years ago
Martin Hansson	4c3917b6f8	Bug#46454: MySQL wrong index optimisation leads to incorrect result & crashes Problem 1: When the 'Using index' optimization is used, the optimizer may still - after cost-based optimization - decide to use another index in order to avoid using a temporary table. But when this happens, the flag to the storage engine to read index only (not table) was still set. Fixed by resetting the flag in the storage engine and TABLE structure in the above scenario, unless the new index allows for the same optimization. Problem 2: When a 'ref' access method was employed by cost-based optimizer, (when the column is non-NULLable), it was assumed that it needed no initialization if 'quick' access methods (since they are based on range scan). When ORDER BY optimization overrides the decision, however, it expects to have this initialized and hence crashes. Fixed in 5.1 (was fixed in 6.0 already) by initializing 'quick' even when there's 'ref' access. mysql-test/r/order_by.result: Bug#46454: Test result. mysql-test/t/order_by.test: Bug#46454: Test case. sql/sql_select.cc: Bug#46454: Problem 1 fixed in make_join_select() Problem 2 fixed in test_if_skip_sort_order() sql/table.h: Bug#46454: Added comment to field.	17 years ago
Alexey Kopytov	885292e424	Bug #46075 : Assertion failed: 0, file .\protocol.cc, line 416 In create_myisam_from_heap() mark all errors as fatal except HA_ERR_RECORD_FILE_FULL for a HEAP table. Not doing so could lead to problems, e.g. in a case when a temporary MyISAM table gets overrun due to its MAX_ROWS limit while executing INSERT/REPLACE IGNORE ... SELECT. The SELECT execution was aborted, but the error was converted to a warning due to IGNORE clause, so neither 'ok' nor 'error' packet could be sent back to the client. This condition led to hanging client when using 5.0 server, or assertion failure in 5.1. mysql-test/r/insert_select.result: Added a test case for bug #46075. mysql-test/t/insert_select.test: Added a test case for bug #46075. sql/sql_select.cc: In create_myisam_from_heap() mark all errors as fatal except HA_ERR_RECORD_FILE_FULL for a HEAP table.	17 years ago
MySQL Build Team	f6435cbff1	Backport into build-200907211706-5.0.82sp1 > ------------------------------------------------------------ > revno: 2772 > revision-id: joro@sun.com-20090615133815-eb007p5793in33p5 > parent: joro@sun.com-20090612140659-4hj1tta9p8wvcw4k > committer: Georgi Kodinov <joro@sun.com> > branch nick: B44810-5.0-bugteam > timestamp: Mon 2009-06-15 16:38:15 +0300 > message: > Bug #44810: index merge and order by with low sort_buffer_size > crashes server! > > The problem affects the scenario when index merge is followed by a filesort > and the sort buffer is not big enough for all the sort keys. > In this case the filesort function will read the data to the end through the > index merge quick access method (and thus closing the cursor etc), > but will leave the pointer to the quick select method in place. > It will then create a temporary file to hold the results of the filesort and > will add it as a sort output file (in sort.io_cache). > Note that filesort will copy the original 'sort' structure in an automatic > variable and restore it after it's done. > As a result at exiting filesort() we have a sort.io_cache filled in and > nothing else (as a result of close of the cursors at end of reading data > through index merge). > Now create_sort_index() will note that there is a select and will clean it up > (as it's been used already by filesort() reading the data in). While doing that > a special case in the index merge destructor will clean up the sort.io_cache, > assuming it's an output of the index merge method and is not needed anymore. > As a result the code that tries to read the data back from the filesort output > will get no data in both memory and disk and will crash. > > Fixed similarly to how filesort() does it : by copying the sort.io_cache structure > to a local variable, removing the pointer to the io_cache (so that it's not freed > by QUICK_INDEX_MERGE_SELECT::~QUICK_INDEX_MERGE_SELECT) and restoring the original > structure (together with the valid pointer) after the cleanup is done. > This is a safe thing to do because all the structures are already cleaned up by > hitting the end of the index merge's read method (QUICK_INDEX_MERGE_SELECT::get_next()) > and the cleanup code being written in a way that tolerates repeating cleanups.	17 years ago
MySQL Build Team	ce72b2ddc5	Backport into build-200907211706-5.0.82sp1 > ------------------------------------------------------------ > revno: 2733 > revision-id: gshchepa@mysql.com-20090430192037-9p1etcynkglte2j3 > parent: aelkin@mysql.com-20090430143246-zfqaz0t7uoluzdz2 > committer: Gleb Shchepa <gshchepa@mysql.com> > branch nick: mysql-5.0-bugteam > timestamp: Fri 2009-05-01 00:20:37 +0500 > message: > Bug #37362: Crash in do_field_eq > > EXPLAIN EXTENDED of nested query containing a error: > > 1054 Unknown column '...' in 'field list' > > may cause a server crash. > > > Parse error like described above forces a call to > JOIN::destroy() on malformed subquery. > That JOIN::destroy function closes and frees temporary > tables. However, temporary fields of these tables > may be listed in st_select_lex::group_list of outer > query, and that st_select_lex may not cleanup them > properly. So, after the JOIN::destroy call that > st_select_lex::group_list may have Item_field > objects with dangling pointers to freed temporary > table Field objects. That caused a crash.	17 years ago
Georgi Kodinov	7a91bf8c91	Bug #46003 and bug #46034 : backported the fixes from azalea.	17 years ago
Georgi Kodinov	33380cf0b7	Bug #36259 (Optimizing with ORDER BY) and bug#45828 (Optimizer won't use partial primary key if another index can prevent filesort The fix for bug #28404 causes the covering ordering indexes to be preferred unconditionally over non-covering and ref indexes. Fixed by comparing the cost of using a covering index to the cost of using a ref index even for covering ordering indexes. Added an assertion to clarify the condition the local variables should be in. mysql-test/include/mix1.inc: Bug #36259: fixed a non-stable test case mysql-test/r/innodb_mysql.result: Bug #36259 and #45828 : test case mysql-test/t/innodb_mysql.test: Bug #36259 and #45828 : test case sql/sql_select.cc: Bug #36259 and #45828 : don't consider covering indexes supperior to ref keys.	17 years ago
Alexey Kopytov	096c12b2c4	Bug #45262 : Bad effects with CREATE TABLE and DECIMAL Using DECIMAL constants with more than 65 digits in CREATE TABLE ... SELECT led to bogus errors in release builds or assertion failures in debug builds. The problem was in inconsistency in how DECIMAL constants and fields are handled internally. We allow arbitrarily long DECIMAL constants, whereas DECIMAL(M,D) columns are limited to M<=65 and D<=30. my_decimal_precision_to_length() was used in both Item and Field code and truncated precision to DECIMAL_MAX_PRECISION when calculating value length without adjusting precision and decimals. As a result, a DECIMAL constant with more than 65 digits ended up having length less than precision or decimals which led to assertion failures. Fixed by modifying my_decimal_precision_to_length() so that precision is truncated to DECIMAL_MAX_PRECISION only for Field object which is indicated by the new 'truncate' parameter. Another inconsistency fixed by this patch is how DECIMAL constants and expressions are handled for CREATE ... SELECT. create_tmp_field_from_item() (which is used for constants) was changed as a part of the bugfix for bug #24907 to handle long DECIMAL constants gracefully. Item_func::tmp_table_field() (which is used for expressions) on the other hand was still using a simplistic approach when creating a Field_new_decimal from a DECIMAL expression. mysql-test/r/type_newdecimal.result: Added a test case for bug #45262. mysql-test/t/type_newdecimal.test: Added a test case for bug #45262. sql/item.cc: Use the new 'truncate' parameter in my_decimal_precision_to_length(). sql/item_cmpfunc.cc: Use the new 'truncate' parameter in my_decimal_precision_to_length(). sql/item_func.cc: 1. Use the new 'truncate' parameter in my_decimal_precision_to_length(). 2. Do not truncate decimal precision to DECIMAL_MAX_PRECISION for additive expressions involving long DECIMAL constants. 3. Fixed an incosistency in how DECIMAL constants and expressions are handled for CREATE ... SELECT. sql/item_func.h: Use the new 'truncate' parameter in my_decimal_precision_to_length(). sql/item_sum.cc: Use the new 'truncate' parameter in my_decimal_precision_to_length(). sql/my_decimal.h: Do not truncate precision to DECIMAL_MAX_PRECISION when calculating length in my_decimal_precision_to_length() if 'truncate' parameter is FALSE. sql/sql_select.cc: 1. Use the new 'truncate' parameter in my_decimal_precision_to_length(). 2. Use a more correct logic when adjusting value's length.	17 years ago
Evgeny Potemkin	93bac51ef3	Bug#45266: Uninitialized variable lead to an empty result. The TABLE::reginfo.impossible_range is used by the optimizer to indicate that the condition applied to the table is impossible. It wasn't initialized at table opening and this might lead to an empty result on complex queries: a query might set the impossible_range flag on a table and when the query finishes, all tables are returned back to the table cache. The next query that uses the table with the impossible_range flag set and an index over the table will see the flag and thus return an empty result. The open_table function now initializes the TABLE::reginfo.impossible_range variable. mysql-test/r/select.result: A test case for the bug#45266: Uninitialized variable lead to an empty result. mysql-test/t/select.test: A test case for the bug#45266: Uninitialized variable lead to an empty result. sql/sql_base.cc: Bug#45266: Uninitialized variable lead to an empty result. The open_table function now initializes the TABLE::reginfo.impossible_range variable. sql/sql_select.cc: Bug#45266: Uninitialized variable lead to an empty result. The open_table function now initializes the TABLE::reginfo.impossible_range variable. sql/structs.h: Bug#45266: Uninitialized variable lead to an empty result. A comment is added.	17 years ago
MySQL Build Team	f5883e8d69	Backport into build-200906240007-5.1.34sp1 > ------------------------------------------------------------ > revno: 2852.12.6 > tags: clone-5.1.35-build, mysql-5.1.35 > revision-id: gshchepa@mysql.com-20090513075139-g50shsfjaf1dstdn > parent: joerg@mysql.com-20090508190407-ymqxmp6daeta6fdj > committer: Gleb Shchepa <gshchepa@mysql.com> > branch nick: mysql-5.1 > timestamp: Wed 2009-05-13 12:51:39 +0500 > message: > Bug #44290: explain crashes for subquery with distinct in > SQL_SELECT::test_quick_select > > The crash was caused by an incomplete cleanup of JOIN_TAB::select > during the filesort of rows for GROUP BY clause inside a subquery. > Queries where a quick index access is replaced with filesort was > was affected. For example: > > SELECT 1 FROM > (SELECT COUNT(DISTINCT c1) FROM t1 > WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x > > Quick index access related data in the SQL_SELECT::test_quick_select > function was inconsistent after an incomplete cleanup. > This function has been completed to prevent crashes in the > SQL_SELECT::test_quick_select function.	17 years ago
Staale Smedseng	3b0e6e4109	Bug #43414 Parenthesis (and other) warnings compiling MySQL with gcc 4.3.2 Compiling MySQL with gcc 4.3.2 and later produces a number of warnings, many of which are new with the recent compiler versions. This bug will be resolved in more than one patch to limit the size of changesets. This is the second patch, fixing more of the warnings.	17 years ago
Georgi Kodinov	6df6c8ee95	Bug #44810 : index merge and order by with low sort_buffer_size crashes server! The problem affects the scenario when index merge is followed by a filesort and the sort buffer is not big enough for all the sort keys. In this case the filesort function will read the data to the end through the index merge quick access method (and thus closing the cursor etc), but will leave the pointer to the quick select method in place. It will then create a temporary file to hold the results of the filesort and will add it as a sort output file (in sort.io_cache). Note that filesort will copy the original 'sort' structure in an automatic variable and restore it after it's done. As a result at exiting filesort() we have a sort.io_cache filled in and nothing else (as a result of close of the cursors at end of reading data through index merge). Now create_sort_index() will note that there is a select and will clean it up (as it's been used already by filesort() reading the data in). While doing that a special case in the index merge destructor will clean up the sort.io_cache, assuming it's an output of the index merge method and is not needed anymore. As a result the code that tries to read the data back from the filesort output will get no data in both memory and disk and will crash. Fixed similarly to how filesort() does it : by copying the sort.io_cache structure to a local variable, removing the pointer to the io_cache (so that it's not freed by QUICK_INDEX_MERGE_SELECT::~QUICK_INDEX_MERGE_SELECT) and restoring the original structure (together with the valid pointer) after the cleanup is done. This is a safe thing to do because all the structures are already cleaned up by hitting the end of the index merge's read method (QUICK_INDEX_MERGE_SELECT::get_next()) and the cleanup code being written in a way that tolerates repeating cleanups. mysql-test/r/index_merge.result: Bug #44810: test case mysql-test/t/index_merge.test: Bug #44810: test case sql/sql_select.cc: Bug #44810: preserve the io_cache produced by filesort while cleaning up the index merge quick access method (QUICK_INDEX_MERGE_SELECT).	17 years ago
Staale Smedseng	a103509788	Bug #43414 Parenthesis (and other) warnings compiling MySQL with gcc 4.3.2 Compiling MySQL with gcc 4.3.2 and later produces a number of warnings, many of which are new with the recent compiler versions. This bug will be resolved in more than one patch to limit the size of changesets. This is the second patch, fixing more of the warnings.	17 years ago
Gleb Shchepa	ed7f0f3023	Bug #44886 : SIGSEGV in test_if_skip_sort_order() - uninitialized variable used as subscript Grouping select from a "constant" InnoDB table (a table of a single row) joined with other tables caused a crash. mysql-test/r/innodb_mysql.result: Added test case for bug bug #44886. mysql-test/t/innodb_mysql.test: Added test case for bug bug #44886. sql/sql_select.cc: Bug #44886: SIGSEGV in test_if_skip_sort_order() - uninitialized variable used as subscript 1. The test_if_order_by_key function returned unitialized used_key_parts parameter in case of a "constant" InnoDB table. Calling function uses this parameter values as an array index, thus sometimes it caused a crash. The test_if_order_by_key function has been modified to set used_key_parts to 0 (no need for ordering). 2. The test_if_skip_sort_order function has been modified to accept zero used_key_parts value and to prevent an array access by negative index.	17 years ago
Tatiana A. Nurnberg	e34085fe13	Bug#32149: Long semaphore wait for adaptive hash latch Holding on to the temporary inno hash index latch is an optimization in many cases, but a pessimization in some others. Release temporary latches for those corner cases we (or rather, or customers, thanks!) have identified, that is, when we are about to do something that might take a really long time, like REPAIR or filesort. sql/ha_myisam.cc: Let go of (inno, for now) latch when doing MyISAM-repair. (optimize passes through repair.) ("Stuck" in "Repair with keycache".) sql/sql_insert.cc: Let go of (inno, for now) latch when doing CREATE...SELECT in select_insert::send_data() -- it might take a while. ("stuck" in "Sending data") sql/sql_select.cc: Release temporary (inno, for now) latch on - free_tmp_table() (this can take surprisingly long, "removing tmp table") - create_myisam_from_heap() (HEAP table overflowing onto disk as MyISAM, "converting HEAP to MyISAM")	17 years ago
Georgi Kodinov	7348140465	Bug #44399 : crash with statement using TEXT columns, aggregates, GROUP BY, and HAVING When calculating GROUP BY the server caches some expressions. It does that by allocating a string slot (Item_copy_string) and assigning the value of the expression to it. This effectively means that the result type of the expression can be changed from whatever it was to a string. As this substitution takes place after the compile-time result type calculation for IN but before the run-time type calculations, it causes the type calculations in the IN function done at run time to get unexpected results different from what was prepared at compile time. In the CASE ... WHEN ... THEN ... statement there was a similar problem and it was solved by artificially adding a STRING argument to the set of types of the IN/CASE arguments at compile time, so if any of the arguments of the CASE function changes its type to a string it will still be covered by the information prepared at compile time. mysql-test/include/mix1.inc: Bug #44399: extended the test to cover the different types mysql-test/r/func_in.result: Bug #44399: test case mysql-test/r/innodb_mysql.result: Bug #44399: extended the test to cover the different types mysql-test/t/func_in.test: Bug #44399: test case sql/item.cc: Bug #44399: Implement typed caching for GROUP BY sql/item.h: Bug #44399: Implement typed caching for GROUP BY sql/item_cmpfunc.cc: Bug #44399: remove the special case sql/sql_select.cc: Bug #44399: Implement typed caching for GROUP BY	17 years ago
Gleb Shchepa	585cf08fe6	Bug #44290 : explain crashes for subquery with distinct in SQL_SELECT::test_quick_select The crash was caused by an incomplete cleanup of JOIN_TAB::select during the filesort of rows for GROUP BY clause inside a subquery. Queries where a quick index access is replaced with filesort was was affected. For example: SELECT 1 FROM (SELECT COUNT(DISTINCT c1) FROM t1 WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x Quick index access related data in the SQL_SELECT::test_quick_select function was inconsistent after an incomplete cleanup. This function has been completed to prevent crashes in the SQL_SELECT::test_quick_select function. mysql-test/include/mix1.inc: Add test case for bug #44290. mysql-test/r/innodb_mysql.result: Add test case for bug #44290. sql/sql_select.cc: Bug #44290: explain crashes for subquery with distinct in SQL_SELECT::test_quick_select Quick index access related data in the SQL_SELECT::test_quick_select function was inconsistent after an incomplete cleanup. This function has been completed to prevent crashes in the SQL_SELECT::test_quick_select function.	17 years ago
Gleb Shchepa	bd59628754	Bug #44290 : explain crashes for subquery with distinct in SQL_SELECT::test_quick_select The crash was caused by an incomplete cleanup of JOIN_TAB::select during the filesort of rows for GROUP BY clause inside a subquery. Queries where a quick index access is replaced with filesort was was affected. For example: SELECT 1 FROM (SELECT COUNT(DISTINCT c1) FROM t1 WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x Quick index access related data in the SQL_SELECT::test_quick_select function was inconsistent after an incomplete cleanup. This function has been completed to prevent crashes in the SQL_SELECT::test_quick_select function. mysql-test/include/mix1.inc: Add test case for bug #44290. mysql-test/r/innodb_mysql.result: Add test case for bug #44290. sql/sql_select.cc: Bug #44290: explain crashes for subquery with distinct in SQL_SELECT::test_quick_select Quick index access related data in the SQL_SELECT::test_quick_select function was inconsistent after an incomplete cleanup. This function has been completed to prevent crashes in the SQL_SELECT::test_quick_select function.	17 years ago
Martin Hansson	fdd5a63fe6	Bug#44306: Assertion fail on duplicate key error in 'INSERT ... SELECT' statements The code that produces result rows expected that a duplicate row error could not occur in INSERT ... SELECT statements with unfulfilled WHERE conditions. This may happen, however, if the SELECT list contains only aggregate functions. Fixed by checking if an error occured before trying to send EOF to the client. mysql-test/r/insert_select.result: Bug#44306: Test result mysql-test/t/insert_select.test: Bug#44306: Test case sql/sql_select.cc: Bug#44306: Fix	17 years ago
Gleb Shchepa	f0791b8b6b	Bug #37362 : Crash in do_field_eq EXPLAIN EXTENDED of nested query containing a error: 1054 Unknown column '...' in 'field list' may cause a server crash. Parse error like described above forces a call to JOIN::destroy() on malformed subquery. That JOIN::destroy function closes and frees temporary tables. However, temporary fields of these tables may be listed in st_select_lex::group_list of outer query, and that st_select_lex may not cleanup them properly. So, after the JOIN::destroy call that st_select_lex::group_list may have Item_field objects with dangling pointers to freed temporary table Field objects. That caused a crash. mysql-test/r/subselect3.result: Added test case for bug #37362. mysql-test/t/subselect3.test: Added test case for bug #37362. sql/sql_select.cc: Bug #37362: Crash in do_field_eq The JOIN::destroy function has been modified to cleanup temporary table column items.	17 years ago
Daniel Fischer	1ba56d53ed	backport #34773 , commit 61127	17 years ago
Daniel Fischer	4c60b1d4b7	backport #42419 , commits 66925, 66999	17 years ago
Gleb Shchepa	02884a4d98	Backport bug #37348 fix 5.1 --> 5.0. Original commentary: Bug #37348: Crash in or immediately after JOIN::make_sum_func_list The optimizer pulls up aggregate functions which should be aggregated in an outer select. At some point it may substitute such a function for a field in the temporary table. The setup_copy_fields function doesn't take this into account and may overrun the copy_field buffer. Fixed by filtering out the fields referenced through the specialized reference for aggregates (Item_aggregate_ref). Added an assertion to make sure bugs that cause similar discrepancy don't go undetected. mysql-test/r/func_group.result: Backport bug #37348 fix 5.1 --> 5.0. mysql-test/t/func_group.test: Backport bug #37348 fix 5.1 --> 5.0. sql/item.cc: Backport bug #37348 fix 5.1 --> 5.0. sql/item.h: Backport bug #37348 fix 5.1 --> 5.0. sql/sql_select.cc: Backport bug #37348 fix 5.1 --> 5.0.	17 years ago

1 2 3 4 5 ...

2412 Commits (16c8298a85619674f1cce46c081e52f4fbeadb33)