mariadb

Commit Graph

Author	SHA1	Message	Date
Ramil Kalimullin	7344b58c32	Fix for bug#49570: Assertion failed: !(order->used & map) on re-execution of prepared statement Problem: some (see eq_ref_table()) ORDER BY/GROUP BY optimization is called before each PS execution. However, we don't properly initialize its stucture every time before the call. Fix: properly initialize the sturture used. mysql-test/r/ps.result: Fix for bug#49570: Assertion failed: !(order->used & map) on re-execution of prepared statement - test result. mysql-test/t/ps.test: Fix for bug#49570: Assertion failed: !(order->used & map) on re-execution of prepared statement - test case. sql/sql_select.cc: Fix for bug#49570: Assertion failed: !(order->used & map) on re-execution of prepared statement - set order->used to 0 before each eq_ref_table() call, as the function relies on that.	16 years ago
Georgi Kodinov	b72f278958	Bug #48709 : Assertion failed in sql_select.cc:11782: int join_read_key(JOIN_TAB*) The eq_ref access method TABLE_REF (accessed through JOIN_TAB) to save state and to track if this is the first row it finds or not. This state was not reset on subquery re-execution causing an assert. Fixed by resetting the state before the subquery re-execution.	16 years ago
Georgi Kodinov	bd308d1256	Bug #42760 : Select doesn't return desired results when we have null values Part 2 : There was a special optimization on the ref access method for ORDER BY ... DESC that was set without actually looking on the type of the selected index for ORDER BY. Fixed the SELECT ... ORDER BY .. DESC (it uses a different code path compared to the ASC that has been fixed with the previous fix).	16 years ago
Ramil Kalimullin	f5b51bc1e2	Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases Building multiple equality predicates containing a constant which is compared as a datetime (with a field) we should take this fact into account and compare the constant with another possible constatns as datetimes as well. E.g. for the SELECT ... WHERE a='2001-01-01' AND a='2001-01-01 00:00:00' we should compare '2001-01-01' with '2001-01-01 00:00:00' as datetimes but not as strings. mysql-test/r/select.result: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - test result. mysql-test/t/select.test: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - test case. sql/item_cmpfunc.cc: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - adding a constant to Item_equal compare it as a datetime value with stored one if there's a date[time] field in a equality predicate. sql/item_cmpfunc.h: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - adding a constant to Item_equal compare it as a datetime value with stored one if there's a date[time] field in a equality predicate. sql/sql_select.cc: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - adding a constant to Item_equal compare it as a datetime value with stored one if there's a date[time] field in a equality predicate.	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
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
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
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
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.	16 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.	16 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.	16 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
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
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
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
Georgi Kodinov	29476d879f	Bug #42419 : Server crash with "Pure virtual method called" on two concurrent connections The problem is that tables can enter open table cache for a thread without being properly cleaned up. This can happen if make_join_statistics() fails to read a const table because of e.g. a deadlock. It does set a member of TABLE structure to a value it allocates, but doesn't clean-up this setting on error nor does it set the rest of the members in JOIN to allow for automatic cleanup. As a result when such an error occurs and the next statement depends re-uses the table from the open tables cache it will get it with this TABLE::reginfo.join_tab pointing to a memory area that's freed. Fixed by making sure make_join_statistics() cleans up TABLE::reginfo.join_tab on error. mysql-test/r/innodb_mysql.result: Bug #42419: test case mysql-test/t/innodb_mysql-master.opt: Bug #42419: increase the timeout so it covers te conservative sleep 3 in the test mysql-test/t/innodb_mysql.test: Bug #42419: test case sql/sql_select.cc: Bug #42419: clean up the members of TABLE on failure in make_join_statisitcs()	17 years ago
Ignacio Galarza	54fbbf9591	Bug#29125 Windows Server X64: so many compiler warnings - Remove bothersome warning messages. This change focuses on the warnings that are covered by the ignore file: support-files/compiler_warnings.supp. - Strings are guaranteed to be max uint in length	17 years ago
Gleb Shchepa	061bf717e0	Bug #42037 : Queries containing a subquery with DISTINCT and ORDER BY could cause a server crash Dependent subqueries like SELECT COUNT() FROM t1, t2 WHERE t2.b IN (SELECT DISTINCT t2.b FROM t2 WHERE t2.b = t1.a) caused a memory leak proportional to the number of outer rows. The make_simple_join() function has been modified to JOIN class method to store join_tab_reexec and table_reexec values in the parent join only (make_simple_join of tmp_join may access these values via 'this' pointer of the parent JOIN). NOTE: this patch doesn't include standard test case (this is "out of memory" bug). See bug #42037 page for test cases. sql/sql_select.cc: Bug #42037: Queries containing a subquery with DISTINCT and ORDER BY could cause a server crash The make_simple_join() function has been modified to JOIN class method to store join_tab_reexec and table_reexec values in the parent join only. sql/sql_select.h: Bug #42037: Queries containing a subquery with DISTINCT and ORDER BY could cause a server crash 1. The make_simple_join() function has been modified to JOIN class method. 2. Type of JOIN::table_reexec field has been changed from TABLE* to TABLE *table_reexec[1]: this field always was NULL or a pointer to one-element array of pointers, so a pointer to a pointer has been replaced with one pointer and unnecessary memory allocation has been eliminated.	17 years ago
Gleb Shchepa	334e249f91	Bug #39069 : <row constructor> IN <table-subquery> seriously messed up "ROW(...) IN (SELECT ... FROM DUAL)" always returned TRUE. Item_in_subselect::row_value_transformer rewrites "ROW(...) IN SELECT" conditions into the "EXISTS (SELECT ... HAVING ...)" form. For a subquery from the DUAL pseudotable resulting HAVING condition is an expression on constant values, so further transformation with optimize_cond() eliminates this HAVING condition and resets JOIN::having to NULL. Then JOIN::exec treated that NULL as an always-true-HAVING and that caused a bug. To distinguish an optimized out "HAVING TRUE" clause from "HAVING FALSE" we already have the JOIN::having_value flag. However, JOIN::exec() ignored JOIN::having_value as described above as if it always set to COND_TRUE. The JOIN::exec method has been modified to take into account the value of the JOIN::having_value field. mysql-test/r/subselect3.result: Added test case for bug #39069. mysql-test/t/subselect3.test: Added test case for bug #39069. sql/sql_select.cc: Bug #39069: <row constructor> IN <table-subquery> seriously messed up The JOIN::exec method has been modified to take into account the value of the JOIN::having_value field.	17 years ago
Georgi Kodinov	ba47e3bc4d	Bug #38795 : Automatic search depth and nested join's results in server crash The greedy optimizer tracks the current level of nested joins and the position inside these by setting and maintaining a state that's global for the whole FROM clause. This state was correctly maintained inside the selection of the next partial plan table (in best_extension_by_limited_search()). greedy_search() also moves the current position by adding the last partial match table when there's not enough tables in the partial plan found by best_extension_by_limited_search(). This may require update of the global state variables that describe the current position in the plan if the last table placed by greedy_search is not a top-level join table. Fixed by updating the state after placing the partial plan table in greedy_search() in the same way this is done on entering the best_extension_by_limited_search(). Fixed the signature of the function called to update the state : check_interleaving_with_nj mysql-test/r/greedy_optimizer.result: Bug #38795: test case mysql-test/t/greedy_optimizer.test: Bug #38795: test case sql/sql_select.cc: Bug #38795: correctly update current position when placing the next partial plan table in greedy_search().	17 years ago
Sergey Glukhov	ce985aa36e	Bug#40953 SELECT query throws "ERROR 1062 (23000): Duplicate entry..." error Table could be marked dependent because it is either 1) an inner table of an outer join, or 2) it is a part of STRAIGHT_JOIN. In case of STRAIGHT_JOIN table->maybe_null should not be assigned. The fix is to set st_table::maybe_null to 'true' only for those tables which are used in outer join. mysql-test/r/select.result: test result mysql-test/t/select.test: test case sql/sql_select.cc: Table could be marked dependent because it is either 1) an inner table of an outer join, or 2) it is a part of STRAIGHT_JOIN. In case of STRAIGHT_JOIN table->maybe_null should not be assigned. The fix is to set st_table::maybe_null to 'true' only for those tables which are used in outer join. sql/sql_select.h: added comment	17 years ago
Sergey Glukhov	84de3b930b	Bug#37956 memory leak and / or crash with geometry and prepared statements! Bug#37671 crash on prepared statement + cursor + geometry + too many open files! if mysql_execute_command() returns error then free materialized_cursor object. is_rnd_inited is added to satisfy rnd_end() assertion (handler may be uninitialized in some cases) sql/sql_cursor.cc: if mysql_execute_command() returns error then free materialized_cursor object. is_rnd_inited is added to satisfy rnd_end() assertion (handler may be uninitialized in some cases) sql/sql_select.cc: added result check tests/mysql_client_test.c: test case	17 years ago
Georgi Kodinov	979974c53b	backported the fix for bug #34773 to 5.0	17 years ago
Sergey Glukhov	4ce563e01c	Bug#31399 Wrong query result when doing join buffering over BIT fields if table has bit fields then uneven bits(if exist) are stored into null bits place. So we need to copy null bits in case of uneven bit field presence. mysql-test/r/type_bit.result: test result mysql-test/t/type_bit.test: test case sql/sql_select.cc: if table has bit fields then uneven bits(if exist) are stored into null bits place. So we need to copy null bits in case of uneven bit field presence.	17 years ago
Georgi Kodinov	d795963cba	Bug #39656 : Behaviour different for agg functions with & without where - ONLY_FULL_GROUP_BY The check for non-aggregated columns in queries with aggregate function, but without GROUP BY was treating all the parts of the query as if they are in the SELECT list. Fixed by ignoring the non-aggregated fields in the WHERE clause. mysql-test/r/func_group.result: Bug #39656: test case mysql-test/t/func_group.test: Bug #39656: test case sql/sql_select.cc: Bug #39656: ignore the new non-aggregated column refs in a WHERE by saving the state so far and then adding only the new values of the other parts of the bitmask.	17 years ago
Alexey Botchkov	d445b215d1	Bug#25058 ignored return codes in memory allocation functions memory allocation error checks added for functions calling insert_dynamic() per-file messages: myisam/mi_delete.c Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled myisam/mi_write.c Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled server-tools/instance-manager/instance_options.cc Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/slave.cc Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/sp_head.cc Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/sp_head.h Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/sp_pcontext.cc Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/sp_pcontext.h Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/sql_select.cc Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled sql/sql_yacc.yy Bug#25058 ignored return codes in memory allocation functions out-of-memory errors handled	17 years ago
Georgi Kodinov	697b2839db	Bug #33811 : Call to stored procedure with SELECT * / RIGHT JOIN fails after the first time Two separate problems : 1. When flattening joins the linked list used for name resolution (next_name_resolution_table) was not updated. Fixed by updating the pointers when extending the table list 2. The items created by expanding a * (star) as a column reference were marked as fixed, but no cached table was assigned to them (unlike what Item_field::fix_fields does). Fixed by assigning a cached table (so the re-preparation is done faster). Note that the fix for #2 hides the fix for #1 in most cases (except when a table reference cannot be cached). mysql-test/r/sp.result: Bug #33811: test case mysql-test/t/sp.test: Bug #33811: test case sql/sql_base.cc: Bug #33811: cache the table for Item_fields created by expanding '*' sql/sql_select.cc: Bug #33811: maintain a correct name resolution chain when flattening joins.	17 years ago
Gleb Shchepa	b591793496	Bug #39844 : Query Crash Mysql Server 5.0.67 Server crashed during a sort order optimization of a dependent subquery: SELECT (SELECT t1.a FROM t1, t2 WHERE t1.a = t2.b AND t2.a = t3.c ORDER BY t1.a) FROM t3; Bitmap of tables, that the reference to outer table column uses, in addition to the regular table bit has the OUTER_REF_TABLE_BIT bit set. The only_eq_ref_tables function traverses this map bit by bit simultaneously with join->map2table list. Obviously join->map2table never contains an entry for the OUTER_REF_TABLE_BIT pseudo-table, so the server crashed there. The only_eq_ref_tables function has been modified to traverse regular table bits only like the update_depend_map function (resetting of the OUTER_REF_TABLE_BIT there is enough, but resetting of the whole set of PSEUDO_TABLE_BITS is used there for sure). mysql-test/r/order_by.result: Added test case for bug #39844. mysql-test/t/order_by.test: Added test case for bug #39844. sql/sql_select.cc: Bug #39844: Query Crash Mysql Server 5.0.67 The only_eq_ref_tables function has been modified to traverse regular table bits only like the update_depend_map function (resetting of the OUTER_REF_TABLE_BIT there is enough, but resetting of the whole set of PSEUDO_TABLE_BITS is used there for sure).	17 years ago
Gleb Shchepa	8bfbcbd981	Bug #39283 : Date returned as VARBINARY to client for queries with COALESCE and JOIN The server returned to a client the VARBINARY column type instead of the DATE type for a result of the COALESCE, IFNULL, IF, CASE, GREATEST or LEAST functions if that result was filesorted in an anonymous temporary table during the query execution. For example: SELECT COALESCE(t1.date1, t2.date2) AS result FROM t1 JOIN t2 ON t1.id = t2.id ORDER BY result; To create a column of various date/time types in a temporary table the create_tmp_field_from_item() function uses the Item::tmp_table_field_from_field_type() method call. However, fields of the MYSQL_TYPE_NEWDATE type were missed there, and the VARBINARY columns were created by default. Necessary condition has been added. mysql-test/r/metadata.result: Added test case for bug #39283. mysql-test/t/metadata.test: Added test case for bug #39283. sql/sql_select.cc: Bug #39283: Date returned as VARBINARY to client for queries with COALESCE and JOIN To create a column of various date/time types in a temporary table the create_tmp_field_from_item() function uses the Item::tmp_table_field_from_field_type() method call. However, fields of the MYSQL_TYPE_NEWDATE type were missed there, and the VARBINARY columns were created by default. Necessary condition has been added.	17 years ago
Evgeny Potemkin	06bf25e4d4	Bug#38195: Incorrect handling of aggregate functions when loose index scan is used causes server crash. When the loose index scan access method is used values of aggregated functions are precomputed by it. Aggregation of such functions shouldn't be performed in this case and functions should be treated as normal ones. The create_tmp_table function wasn't taking this into account and this led to a crash if a query has MIN/MAX aggregate functions and employs temporary table and loose index scan. Now the JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate functions as normal ones when the loose index scan is used. mysql-test/r/group_min_max.result: Added a test case for the bug#38195. mysql-test/t/group_min_max.test: Added a test case for the bug#38195. sql/sql_select.cc: Bug#38195: Incorrect handling of aggregate functions when loose index scan is used causes server crash. The JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate functions as normal ones when the loose index scan is used.	17 years ago
Georgi Kodinov	6387cac94b	Bug#38195: Incorrect handling of aggregate functions when loose index scan is used causes server crash. Revert the fix : unstable test case revealed by pushbuild	17 years ago
Evgeny Potemkin	b789b4f33c	Bug#38195: Incorrect handling of aggregate functions when loose index scan is used causes server crash. When the loose index scan access method is used values of aggregated functions are precomputed by it. Aggregation of such functions shouldn't be performed in this case and functions should be treated as normal ones. The create_tmp_table function wasn't taking this into account and this led to a crash if a query has MIN/MAX aggregate functions and employs temporary table and loose index scan. Now the JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate functions as normal ones when the loose index scan is used. mysql-test/r/group_min_max.result: Added a test case for the bug#38195. mysql-test/t/group_min_max.test: Added a test case for the bug#38195. sql/sql_select.cc: Bug#38195: Incorrect handling of aggregate functions when loose index scan is used causes server crash. Now the JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate functions as normal ones when the loose index scan is used.	18 years ago
Igor Babaev	b6e3a9e28c	Fixed bug #38191 . Calling List<Cached_item>::delete_elements for the same list twice caused a crash of the server in the function JOIN::cleaunup. Ensured that delete_elements() in JOIN::cleanup would be called only once. mysql-test/r/subselect.result: Added a test case for bug #38191. mysql-test/t/subselect.test: Added a test case for bug #38191. sql/sql_select.cc: Fixed bug #38191. Ensured that delete_elements() in JOIN::cleanup would be called only once.	18 years ago
Georgi Kodinov	dd85aa78ba	Bug#37830 : ORDER BY ASC/DESC - no difference Range scan in descending order for c <= <col> <= c type of ranges was ignoring the DESC flag. However some engines like InnoDB have the primary key parts as a suffix for every secondary key. When such primary key suffix is used for ordering ignoring the DESC is not valid. But we generally would like to do this because it's faster. Fixed by performing only reverse scan if the primary key is used. Removed some dead code in the process. mysql-test/r/innodb_mysql.result: Bug#37830 : test case mysql-test/t/innodb_mysql.test: Bug#37830 : test case sql/opt_range.cc: Bug#37830 : - preserve and use used_key_parts to distinguish when a primary key suffix is used - removed some dead code sql/opt_range.h: Bug#37830 : - preserve used_key_parts - dead code removed sql/sql_select.cc: Bug#37830 : Do only reverse order traversal if the primary key suffix is used.	18 years ago

1 2 3 4 5 ...

1914 Commits (0a64fbc517eef4550e5b0b75246125391f5deca1)