1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-10 04:22:00 +03:00
Commit Graph

2492 Commits

Author SHA1 Message Date
a0bea5eeb1 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.
2009-10-30 15:15:43 +02:00
e8c608fe72 merge 2009-10-30 11:56:32 +02:00
7ba875d6e6 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.
2009-10-30 11:40:44 +02:00
0dea5a630b merge 2009-10-30 10:03:18 +02:00
1d8cceae2b 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.
2009-10-29 17:24:29 +02:00
256e3ec03b 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.
2009-10-21 14:04:08 +05:00
51ff23f0f0 Autopush 2009-10-22 14:40:15 +05:00
a91b18262c 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.
2009-10-14 18:20:01 +02:00
bf0aa2bd34 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.
2009-10-14 10:46:50 +02:00
5faf23bf55 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.
2009-10-07 18:03:42 +03:00
406e680b25 Automerge. 2009-10-30 19:16:25 +03:00
0213cd7976 merge 2009-09-28 16:48:40 +03:00
185698530e 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).
2009-09-23 13:40:33 +05:00
a31f655d82 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.
2009-09-18 12:34:08 +03:00
38b6d49e82 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().
2009-09-17 17:10:30 +02:00
3ec517416b automerge 2009-09-08 12:37:09 +03:00
97920d3ad9 Automerge. 2009-09-08 12:36:40 +04:00
f161723821 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().
2009-09-06 00:42:17 +04:00
510eac6ec1 5.0-bugteam->5.1-bugteam merge 2009-09-04 12:39:56 +05:00
e1d49b8143 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.
2009-09-04 12:20:53 +05:00
acc76a97a0 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.
2009-09-03 18:03:46 +03:00
4adb05e282 automerge 2009-08-31 16:40:35 +03:00
8ca8f70daa 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.
2009-08-27 14:40:42 +03:00
31afccc407 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.
2009-08-24 16:47:08 -03:00
ec7ea44541 Automerge. 2009-07-24 16:13:31 +04:00
c76f98a5f0 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.
2009-07-24 15:50:45 +04:00
127296601d Bug #46003 and bug #46034: backported the fixes from azalea. 2009-07-16 15:19:22 +03:00
5421a8e858 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.
2009-08-07 13:51:40 +02:00
97069a8154 Automerge. 2009-07-24 16:14:14 +04:00
64f6fb7c8f Manual merge. 2009-07-24 16:09:35 +04:00
a304517894 automerge 2009-07-16 16:17:47 +03:00
d9e82ba86c 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.
2009-07-07 15:52:34 +03:00
0c5207f52f Automerge. 2009-07-03 14:43:54 +04:00
c936b6444a Manual merge. 2009-07-03 14:36:04 +04:00
4692566f9e 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.
2009-07-03 11:41:19 +04:00
0e64988a5e 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.
2009-06-26 19:57:42 +00:00
c429fac63c Merge from 5.0-bugteam 2009-06-17 16:56:44 +02:00
30fccdaaae 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.
2009-06-17 15:54:01 +02:00
3fe572dd06 automerge 2009-06-15 17:36:51 +03:00
b1560b9f2f 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.
2009-06-15 16:38:15 +03:00
e6e1f4ac84 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.
2009-06-10 16:04:07 +02:00
eecf06873e 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.
2009-06-08 01:40:53 +05:00
640b7cd6e2 auto-merge 2009-06-05 01:30:08 +02:00
b89d2fce58 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.
2009-06-05 00:23:08 +02:00
8fb82e3fe0 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.
2009-05-25 11:00:40 +03:00
803ce846a3 merged 5.0-main -> 5.0-bugteam 2009-05-15 12:29:41 +03:00
2121599d38 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.
2009-05-12 22:42:31 +05:00
128afdc3e5 Merge community up to enterprise, thus ending the community-server
adventure.
2009-05-06 09:06:32 -04:00
ce10b71bc9 Bug#44306: Assertion fail on duplicate key error in
'INSERT ... SELECT' statements

Merge
2009-05-04 14:57:42 +02:00
8fa68f5719 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.
2009-05-04 14:45:36 +02:00