The crash happens because select_union object is used as result set
for queries which have derived tables.
select_union use temporary table as data storage and if
fields count exceeds 10(count of values for procedure ANALYSE())
then we get a crash on fill_record() function.
view that has Group By
Table access rights checking function check_grant() assumed
that no view is opened when it's called.
This is not true with nested views where the inner view
needs materialization. In this case the view is already
materialized when check_grant() is called for it.
This caused check_grant() to not look for table level
grants on the materialized view table.
Fixed by checking if a view is already materialized and if
it is check table level grants using the original table name
(not the ones of the materialized temp table).
Replication SQL thread does not set database default charset to
thd->variables.collation_database properly, when executing LOAD DATA binlog.
This bug can be repeated by using "LOAD DATA" command in STATEMENT mode.
This patch adds code to find the default character set of the current database
then assign it to thd->db_charset when slave server begins to execute a relay log.
The test of this bug is added into rpl_loaddata_charset.test
The problem is that the lexer could inadvertently skip over the
end of a query being parsed if it encountered a malformed multibyte
character. A specially crated query string could cause the lexer
to jump up to six bytes past the end of the query buffer. Another
problem was that the laxer could use unfiltered user input as
a signed array index for the parser maps (having upper and lower
bounds 0 and 256 respectively).
The solution is to ensure that the lexer only skips over well-formed
multibyte characters and that the index value of the parser maps
is always a unsigned value.
Install procedure does not copy *.inc files located under the mysql-test/t directory.
Therefore, this patch moves the rpl_trigger.inc to the mysql-test/include directory.
The test case fails sporadically on Windows while trying to overwrite an unused
binary log. The problem stems from the fact that MySQL on Windows does not
immediately unlock/release a file while the process that opened and closed it is
still running. In BUG 38603, this issue was circumvented by stopping the MySQL
process, copying the file and then restarting the MySQL process.
Unfortunately, such facilities are not available in the 5.0. Other approaches
such as stopping the slave and issuing change master do not work because the relay
log file and index are not closed when a slave is stopped. So to fix the problem,
we simply don't run on windows the part of the test that was failing.
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.
> ------------------------------------------------------------
> 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.
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.
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.
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.
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()
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.
BUG#40565 - Update Query Results in "1 Row Affected" But Should Be "Zero Rows"
Detailed revision comments:
r5232 | marko | 2009-06-03 14:31:04 +0300 (Wed, 03 Jun 2009) | 21 lines
branches/5.0: Merge r3590 from branches/5.1 in order to fix Bug #40565
(Update Query Results in "1 Row Affected" But Should Be "Zero Rows").
Also, add a test case for Bug #40565.
rb://128 approved by Heikki Tuuri
------------------------------------------------------------------------
r3590 | marko | 2008-12-18 15:33:36 +0200 (Thu, 18 Dec 2008) | 11 lines
branches/5.1: When converting a record to MySQL format, copy the default
column values for columns that are SQL NULL. This addresses failures in
row-based replication (Bug #39648).
row_prebuilt_t: Add default_rec, for the default values of the columns in
MySQL format.
row_sel_store_mysql_rec(): Use prebuilt->default_rec instead of
padding columns.
rb://64 approved by Heikki Tuuri
------------------------------------------------------------------------
Details:
- Limit the queries to character sets and collations
which are most probably available in all build types.
But try to preserve the intention of the tests.
- Remove the variants adjusted to some build types.
Note:
1. The results of the review by Bar are included.
2. I am not able to check the correctness of this patch
on any existing build type and any MySQL version.
So it could happen that the new test fails somewhere.
Inconsistent behavior of session variable max_allowed_packet
(and net_buffer_length); only assignment to the global variable
has any effect, without this being obvious to the user.
The patch for Bug#22891 is backported to 5.0, making the two
session variables read-only. As this is a backport to GA
software, the error used when trying to assign to the read-
only variable is ER_UNKNOWN_ERROR. The error message is the
same as in 5.1+.
