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.
Problem was that a failing rename just left the partitions at the state
it was at the failure.
Solution was to try to revert the started rename if a failure occured.
mysql-test/r/partition_not_embedded.result:
Bug#30102: Rename table does corrupt tables with partition files on failure
New result file
mysql-test/t/partition_not_embedded.test:
Bug#30102: Rename table does corrupt tables with partition files on failure
New test file
(list_files does not report the files in embedded)
sql/ha_partition.cc:
Bug#30102: Rename table does corrupt tables with partition files on failure
Better error handling for rename partitions (reverting the started rename
operation)
Different order of files for delete.
sql/handler.cc:
Bug#30102: Rename table does corrupt tables with partition files on failure
Tries to remove as many table files as possible
if the first delete succeeds.
> ------------------------------------------------------------
> revno: 2792
> revision-id: sergey.glukhov@sun.com-20090703083500-jq8vhw0tqr37j7te
> parent: bernt.johnsen@sun.com-20090703083610-o7l4s8syz05rc4w0
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.0-bugteam
> timestamp: Fri 2009-07-03 13:35:00 +0500
> message:
> Bug#45806 crash when replacing into a view with a join!
> The crash happend because for views which are joins
> we have table_list->table == 0 and
> table_list->table->'any method' call leads to crash.
> The fix is to perform table_list->table->file->extra()
> method for all tables belonging to view.
> ------------------------------------------------------------
> 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.
> ------------------------------------------------------------
> revno: 2763
> revision-id: sergey.glukhov@sun.com-20090602063813-33mh88cz5vpa2jqe
> parent: alexey.kopytov@sun.com-20090601124224-zgt3yov9wou590e9
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.0-bugteam
> timestamp: Tue 2009-06-02 11:38:13 +0500
> message:
> Bug#45152 crash with round() function on longtext column in a derived table
> The crash happens due to wrong max_length value which is set on
> Item_func_round::fix_length_and_dec() stage. The value is set to
> args[0]->max_length which is too big in case of LONGTEXT(LONGBLOB) fields.
> The fix is to set max_length using float_length() function.
> ------------------------------------------------------------
> 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.
When during the optimization an item is moved to the upper select
the item's context left unchanged. This caused wrong result in the
PS/SP mode.
The Item_ident::remove_dependence_processor now sets the context
of the select to which the item is moved to.
mysql-test/r/subselect.result:
The test case for the bug#46051 is adjusted.
mysql-test/t/subselect.test:
The test case for the bug#46051 is adjusted.
sql/item.cc:
Bug#46051: Incorrectly market field caused wrong result.
The Item_ident::remove_dependence_processor now sets the context
of the select to which the item is moved to.
In a subselect all fields from outer selects are marked as dependent on
selects they are belong to. In some cases optimizer substitutes it for an
equivalent expression. For example "a_field IN (SELECT outer_field)" is
substituted with "a_field = outer_field". As we moved the outer_field to the
upper select it's not really outer anymore. But it was left marked as outer.
If exists an index over a_field optimizer choose wrong execution plan and thus
return wrong result.
Now the Item_in_subselect::single_value_transformer function removes dependent
marking from fields when a subselect is optimized away.
mysql-test/r/subselect.result:
Added a test case for the bug#46051.
mysql-test/t/subselect.test:
Added a test case for the bug#46051.
sql/item_subselect.cc:
Bug#46051: Incorrectly market field caused wrong result.
Now the Item_in_subselect::single_value_transformer function removes dependent
marking from fields when a subselect is optimized away.
table
The MERGE table storage engine does not support the HA_CAN_SQL_HANDLE feature
and any attempt to open the merge table will fail with ER_ILLEGAL_HA.
After an error occurred the tables that was opened must be closed again
or they will be left in an inconsistent state. However, the assumption
made in the code for closing and register handler tables was that only
one table will be opened, and this is not true for MERGE tables which
will cause multiple tables to open.
The next time a SELECT operation was issued on the merge table it
caused the system to freeze.
This patch fixes this issue by making sure that all tables which
are opened also are closed in the event of an error.
mysql-test/r/merge.result:
Added test case for bug 45781
mysql-test/t/merge.test:
Added test case for bug 45781
sql/sql_handler.cc:
* mysql_ha_open() was never ment to open more than one table. If we encounter more tables, we should
close all tables related to the current substatement and raise an exception.
match against.
Server crashes when executing prepared statement with duplicating
MATCH() function calls in SELECT and ORDER BY expressions, e.g.:
SELECT MATCH(a) AGAINST('test') FROM t1 ORDER BY MATCH(a) AGAINST('test')
This query gets optimized by the server, so the value returned
by MATCH() from the SELECT list is reused for ORDER BY purposes.
To make this optimization server is comparing items from
SELECT and ORDER BY lists. We were getting server crash because
comparision function for MATCH() item is not intended to be called
at this point of execution.
In 5.0 and 5.1 this problem is workarounded by resetting MATCH()
item to the state as it was during PREPARE.
In 6.0 correct comparision function will be implemented and
duplicating MATCH() items from the ORDER BY list will be
optimized.
mysql-test/r/fulltext.result:
Updated with the test case for Bug#37740
mysql-test/t/fulltext.test:
A test case for Bug#37740.
sql/item_func.h:
True initialization of 'table' happens in ::fix_fields(). As
Item_func_match::eq() may be called before ::fix_fields(), it is
expected that 'table' is initialized to 0 when it is reused.
This is mostly affecting prepared statements, when the same item
doesn't get destroyed, but rather cleaned up and reused.
without error
When using quick access methods for searching rows in UPDATE or
DELETE there was no check if a fatal error was not already sent
to the client while evaluating the quick condition.
As a result a false OK (following the error) was sent to the
client and the error was thus transformed into a warning.
Fixed by checking for errors sent to the client during
SQL_SELECT::check_quick() and treating them as real errors.
Fixed a wrong test case in group_min_max.test
Fixed a wrong return code in mysql_update() and mysql_delete()
mysql-test/r/bug40113.result:
Bug #40013: test case
mysql-test/r/group_min_max.result:
Bug #40013: fixed a wrong test case
mysql-test/t/bug40113-master.opt:
Bug #40013: test case
mysql-test/t/bug40113.test:
Bug #40013: test case
mysql-test/t/group_min_max.test:
Bug #40013: fixed a wrong test case
sql/sql_delete.cc:
Bug #40113: check for errors evaluating the quick select
sql/sql_update.cc:
Bug #40113: check for errors evaluating the quick select
mutually-nested subqueries
Queries of the form
SELECT * FROM (SELECT 1) AS t1,
(SELECT 2) AS t2,...
(SELECT 32) AS t32
caused the "Too high level of nesting for select" error
as if the query has a form
SELECT * FROM (SELECT 1 FROM (SELECT 2 FROM (SELECT 3 FROM...
The table_factor parser rule has been modified to adjust
the LEX::nest_level variable value after every derived table.
mysql-test/r/derived.result:
Added test case for bug #41156.
mysql-test/t/derived.test:
Added test case for bug #41156.
sql/sql_yacc.yy:
Bug #41156: List of derived tables acts like a chain of
mutually-nested subqueries
The select_derived2 parser rule calls mysql_new_select()
calls push_context() and nest_level++, however only
the pop_context() was called at the end of derived table
parsing at the table_factor rule.
The table_factor parser rule has been modified to adjust
the LEX::nest_level variable value after every derived table.
sort_buffer_size cannot allocate
The NULL return from tree_insert() (on low memory) was not
checked for in Item_func_group_concat::add(). As a result
on low memory conditions a crash happens.
Fixed by properly checking the return code.
1. BUG#21704 - Renaming column does not update FK definition
2. Changes in mysql-test/include/mtr_warnings.sql so that the testcase
for BUG#21704 doesn't fail because of the warnings generated.
Detailed revision comments:
r5488 | vasil | 2009-07-09 19:16:44 +0300 (Thu, 09 Jul 2009) | 13 lines
branches/5.1:
Fix Bug#21704 Renaming column does not update FK definition
by checking whether a column that participates in a FK definition is being
renamed and denying the ALTER in this case.
The patch was originally developed by Davi Arnaut <Davi.Arnaut@Sun.COM>:
http://lists.mysql.com/commits/77714
and was later adjusted to conform to InnoDB coding style by me (Vasil),
I also added some more comments and moved the bug specific mysql-test to
a separate file to make it more manageable and flexible.
and base tables
myrg_attach_children() could reuse a buffer that was allocated
previously based on a definition of a child table. The problem
was that the child's definition might have been changed, so
reusing the buffer could lead to crashes or valgrind errors
under some circumstances.
Fixed by changing myrg_attach_children() so that the
rec_per_key_part buffer is reused only when the child table
have not changed, and reallocated otherwise (the old buffer is
deallocated if necessary).
include/myisammrg.h:
Added a pointer to need_compat_check as an argument to
myrg_attach_children().
mysql-test/r/merge.result:
Added a test case for bug #45796.
mysql-test/t/merge.test:
Added a test case for bug #45796.
storage/myisammrg/ha_myisammrg.cc:
Pass a pointer to need_compat_check to myrg_attach_children().
storage/myisammrg/myrg_open.c:
Changed myrg_attach_children() so that the
rec_per_key_part buffer is reused only when the child table
have not changed, and reallocated otherwise (the old buffer
is deallocated if necessary).
BUG#45749 - Race condition in SET GLOBAL innodb_commit_concurrency=DEFAULT
Detailed revision comments:
r5419 | marko | 2009-06-25 16:11:57 +0300 (Thu, 25 Jun 2009) | 18 lines
branches/5.1: Merge r5418 from branches/zip:
------------------------------------------------------------------------
r5418 | marko | 2009-06-25 15:55:52 +0300 (Thu, 25 Jun 2009) | 5 lines
Changed paths:
M /branches/zip/ChangeLog
M /branches/zip/handler/ha_innodb.cc
M /branches/zip/mysql-test/innodb_bug42101-nonzero.result
M /branches/zip/mysql-test/innodb_bug42101-nonzero.test
M /branches/zip/mysql-test/innodb_bug42101.result
M /branches/zip/mysql-test/innodb_bug42101.test
branches/zip: Fix a race condition caused by
SET GLOBAL innodb_commit_concurrency=DEFAULT. (Bug #45749)
When innodb_commit_concurrency is initially set nonzero,
DEFAULT would change it back to 0, triggering Bug #42101.
rb://139 approved by Heikki Tuuri.
------------------------------------------------------------------------
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.
The crash happend because for views which are joins
we have table_list->table == 0 and
table_list->table->'any method' call leads to crash.
The fix is to perform table_list->table->file->extra()
method for all tables belonging to view.
mysql-test/r/view.result:
test result
mysql-test/t/view.test:
test case
sql/sql_insert.cc:
added prepare_for_positional_update() function
which updates extra info about primary key for
tables belonging to view.
enabled message storing into error message list
for 'drop table' command
mysql-test/r/warnings.result:
test result
mysql-test/t/warnings.test:
test case
sql/sql_table.cc:
We should skip error sending then we should return
warnings to client as some functions may send its
own errors, so we should set no_warnings_for_error= 0
only in case of warning.
The fix is to enable message storing into error message
list for 'drop table' command(only for error case).
tests/mysql_client_test.c:
test fix
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.
