push_warning(MYSQL_ERROR::WARN_LEVEL_ERROR)).
The Signal/Resignal patch changes the push_warning() API: now
it silently downgrades WARN_LEVEL_ERROR to WARN_LEVEL_WARN.
This patch should be rolled back when Bug#47233 is fixed.
During insert, we are not reading the rows in a referring table but
instead using the last read row that happens to be in table->record[0].
Now INSERT into such view is denied.
mysql-test/r/delayed.result:
A test case result is adjusted after fixing bug#41760.
mysql-test/r/insert.result:
A test case result is adjusted after fixing bug#41760.
mysql-test/t/delayed.test:
A test case is adjusted after fixing bug#41760.
mysql-test/t/insert.test:
A test case is adjusted after fixing bug#41760.
BUG#38049 "incorrect rows estimations with references from preceding table"
(from revid:sergefp@mysql.com-20090126194259-ue20il3qro529l4d).
Compared to 6.0 where EXPLAIN indicates "Using index condition", here in join_optimizer.result
we see "Using where"; it's normal; 6.0 shows the same if disabling Index Condition Pushdown.
EXPLAIN EXTENDED warning.
Query optimizer searches for the constant tables and optimizes them away. This
means that fields of such tables are substituted for their values and on later
phases they are treated as constants. After this constant tables are removed
from the query execution plan. Nevertheless constant tables were shown in
the EXPLAIN EXTENDED warning thus producing query that might be not an
equivalent of the original query.
Now the print_join function skips all tables that were optimized away from
printing to the EXPLAIN EXTENDED warning. If all tables were optimized away it
produces the 'FROM dual' clause.
mysql-test/r/explain.result:
A test case added for the bug#30302.
mysql-test/r/func_default.result:
Adjusted test case result after fix for the bug#30302.
mysql-test/r/func_regexp.result:
Adjusted test case result after fix for the bug#30302.
mysql-test/r/func_test.result:
Adjusted test case result after fix for the bug#30302.
mysql-test/r/having.result:
Adjusted test case result after fix for the bug#30302.
mysql-test/r/select.result:
Adjusted test case result after fix for the bug#30302.
mysql-test/r/subselect.result:
Adjusted test case result after fix for the bug#30302.
mysql-test/r/subselect3.result:
Adjusted test case result after fix for the bug#30302.
mysql-test/r/type_datetime.result:
Adjusted test case result after fix for the bug#30302.
mysql-test/t/explain.test:
A test case added for the bug#30302.
sql/sql_select.cc:
Bug#30302: Tables that were optimized away are printed in the
EXPLAIN EXTENDED warning.
Now the print_join function skips all tables that were optimized away from
printing to the EXPLAIN EXTENDED warning. If all tables were optimized away it
produces the 'FROM dual' clause.
sql/table.h:
Adjusted test case result after fix for the bug#30302.
The optimized_away flag is added to the TABLE_LIST struct.
mysql-test/r/loadxml.result
mysql-test/t/loadxml.test
Fixing non-deterministic test results
sql/sql_yacc.yy
Initializing fname_first using get_tok_end() instead of get_ptr().
The latter is grammar-dependant. The former is not.
columns without where/group
Simple SELECT with implicit grouping used to return many rows if
the query was ordered by the aggregated column in the SELECT
list. This was incorrect because queries with implicit grouping
should only return a single record.
The problem was that when JOIN:exec() decided if execution needed
to handle grouping, it was assumed that sum_func_count==0 meant
that there were no aggregate functions in the query. This
assumption was not correct in JOIN::exec() because the aggregate
functions might have been optimized away during JOIN::optimize().
The reason why queries without ordering behaved correctly was
that sum_func_count is only recalculated if the optimizer chooses
to use temporary tables (which it does in the ordered case).
Hence, non-ordered queries were correctly treated as grouped.
The fix for this bug was to remove the assumption that
sum_func_count==0 means that there is no need for grouping. This
was done by introducing variable "bool implicit_grouping" in the
JOIN object.
mysql-test/r/func_group.result:
Add test for BUG#47280
mysql-test/t/func_group.test:
Add test for BUG#47280
sql/opt_sum.cc:
Improve comment for opt_sum_query()
sql/sql_class.h:
Add comment for variables in TMP_TABLE_PARAM
sql/sql_select.cc:
Introduce and use variable implicit_grouping instead of (!group_list && sum_func_count) in places that need to test if grouping is required. Also added comments for: optimization of aggregate fields for implicitly grouped queries (JOIN::optimize) and choice of end_select method (JOIN::execute)
sql/sql_select.h:
Add variable implicit_grouping, which will be TRUE for queries that contain aggregate functions but no GROUP BY clause. Also added comment to sort_and_group variable.
Bug #33629: last_day function can return null, but has 'not null' flag set for result
LAST_DAY and MAKEDATE functions are documented as
returning NULL value, but actually they was implemented
as returning NOT NULL typed values.
That caused a confusing error "ERROR 1048 (23000): Column
'...' cannot be null" on queries like:
SELECT 1 FROM (SELECT LAST_DAY('0')) a;
mysql-test/r/func_sapdb.result:
Updated test case for bug #33629.
mysql-test/r/func_time.result:
Updated test case for bug #33629.
mysql-test/r/type_date.result:
Added test case for bug #33629.
mysql-test/t/type_date.test:
Added test case for bug #33629.
sql/item_timefunc.h:
Bug #33629: last_day function can return null, but has 'not null' flag set for result
1. The Item_func_makedate::fix_length_and_dec method
has been modified to declare MAKEDATE() as a function
returning nullable value.
2. The Item_func_last_day::fix_length_and_dec method
has been overloaded for the same purpose.
The problem was in incorrect handling of predicates involving
NULL as a constant value by the range optimizer.
For example, when creating a SEL_ARG node from a condition of
the form "field < const" (which would normally result in the
"NULL < field < const" SEL_ARG), the special case when "const"
is NULL was not taken into account, so "NULL < field < NULL"
was produced for the "field < NULL" condition.
As a result, SEL_ARG structures of this form could not be
further optimized which in turn could lead to incorrectly
constructed SEL_ARG trees. In particular, code assuming SEL_ARG
structures to always form a sequence of ordered disjoint
intervals could enter an infinite loop under some
circumstances.
Fixed by changing get_mm_leaf() so that for any sargable
predicate except "<=>" involving NULL as a constant, "empty"
SEL_ARG is returned, since such a predicate is always false.
mysql-test/r/range.result:
Added a test case for bug #47123.
mysql-test/t/range.test:
Added a test case for bug #47123.
sql/opt_range.cc:
Fixed get_mm_leaf() so that for any sargable
predicate except "<=>" involving NULL as a constant, "empty"
SEL_ARG is returned, since such a predicate is always false.
In MySQL when the mapping for space is changed to something other than
0x20 by defining a different collation, then space is not ignored when
comparing two strings.
This was happening because the function that performs the comparison
of two strings while ignoring ending spaces, was comparing the collation
value of a space with the ascii value of the ' ' character. This should
be changed to do comparison between the collated values.
mysql-test/r/ctype_ldml.result:
Bug#46448 trailing spaces are not ignored when user collation maps space != 0x20
Result file for test case.
mysql-test/std_data/Index.xml:
Bug#46448 trailing spaces are not ignored when user collation maps space != 0x20
Added entry for new test collation in the index file.
mysql-test/std_data/latin1.xml:
Bug#46448 trailing spaces are not ignored when user collation maps space != 0x20
Added support for new collation for test.
mysql-test/t/ctype_ldml.test:
Bug#46448 trailing spaces are not ignored when user collation maps space != 0x20
Added test case to ensure trailing spaces are not ignored.
strings/ctype-simple.c:
Bug#46448 trailing spaces are not ignored when user collation maps space != 0x20
change my_strnncollsp_simple to compare collated values when checking
for trailing spaces. Currently the comparison happens between a collated
value and the ascii value.
low myisam_sort_buffer_size
Repair by sort (default) or parallel repair of a MyISAM table
(doesn't matter partitioned or not) as well as bulk inserts
and enable indexes some times didn't failover to repair with
key cache.
The problem was that after unsuccessful attempt, data file was
closed. Whereas repair with key cache requires open data file.
Fixed by reopening data file.
Also fixed a valgrind warning, which may appear during repair
by sort or parallel repair with certain myisam_sort_buffer_size
number of rows and length of an index entry (very dependent).
mysql-test/r/myisam.result:
A test case for BUG#47073.
mysql-test/t/myisam.test:
A test case for BUG#47073.
storage/myisam/ha_myisam.cc:
Reverted fix for BUG25289. Not needed anymore.
storage/myisam/mi_check.c:
Reopen data file, when repair by sort or parallel repair
fails.
When repair by sort is requested to rebuild data file, data file
gets rebuilt while fixing first index. When rebuild is completed,
info->dfile is pointing to temporary data file, original data file
is closed.
It may happen that repair has successfully fixed first index and
rebuilt data file, but failed to fix second index. E.g.
myisam_sort_buffer_size was big enough to fix first shorter index,
but not enough to fix subsequent longer index.
In this case we end up with info->dfile pointing to temporary file,
which is removed and info->dfile is set to -1.
Though repair by sort failed, the upper layer may still want to
try repair with key cache. But it needs info->dfile pointing to
valid data file.
storage/myisam/sort.c:
When performing a copy of IO_CACHE structure, current_pos and
current_end must be updated separatly to point to memory we're
copying to (not to memory we're copying from).
As t_file2 is always WRITE cache, proper members are write_pos
and write_end accordingly.
Original revision in 6.0:
------------------------------------------------------------
revno: 2599.108.1
committer: Alexander Nozdrin <alik@sun.com>
branch nick: 6.0-rpl-bug40128
timestamp: Wed 2009-01-21 15:33:42 +0300
message:
Fix for Bug#40128: drop-no_root fails under windows in 6.0-rpl.
The problem was that directories with no permission (000) files
are deleted differently on UNIX and on Windows.
On UNIX, 000-permission file is deleted perfectly, but other files
are left in the directory.
On Windows, 000-permission file is not deleted, but other files
are deleted.
Also, the fix needed a change in mysqltest.c: 'chmod' directive
should return a positive error code (in order to be handled).
It's decided to return a constant '1' for all error codes
just to be OS-independent.
------------------------------------------------------------
covering index
When two range predicates were combined under an OR
predicate, the algorithm tried to merge overlapping ranges
into one. But the case when a range overlapped several other
ranges was not handled. This lead to
1) ranges overlapping, which gave repeated results and
2) a range that overlapped several other ranges was cut off.
Fixed by
1) Making sure that a range got an upper bound equal to the
next range with a greater minimum.
2) Removing a continue statement
mysql-test/r/group_min_max.result:
Bug#42846: Changed query plans
mysql-test/r/range.result:
Bug#42846: Test result.
mysql-test/t/range.test:
Bug#42846: Test case.
sql/opt_range.cc:
Bug#42846: The fix.
Part1: Previously, both endpoints from key2 were copied,
which is not safe. Since ranges are processed in ascending
order of minimum endpoints, it is safe to copy the minimum
endpoint from key2 but not the maximum. The maximum may only
be copied if there is no other range or the other range's
minimum is greater than key2's maximum.
backport for bug#44059 from mysql-pe to mysql-5.1-bugteam
Using the partition with most rows instead of first partition
to estimate the cardinality of indexes.
mysql-test/r/partition.result:
Bug#44059: Incorrect cardinality of indexes on a partitioned table
Added test result
mysql-test/t/partition.test:
Bug#44059: Incorrect cardinality of indexes on a partitioned table
Added test case
sql/ha_partition.cc:
Bug#44059: Incorrect cardinality of indexes on a partitioned table
Checking which partition that has the most rows, and using that
partition for HA_STATUS_CONST instead of first partition
is reached
Problem was bad error handling, leaving some new temporary
partitions locked and initialized and some not yet initialized
and locked, leading to a crash when trying to unlock the not
yet initialized and locked partitions
Solution was to unlock the already locked partitions, and not
include any of the new temporary partitions in later unlocks
mysql-test/r/partition_open_files_limit.result:
Bug#46922: crash when adding partitions and open_files_limit
is reached
New test result
mysql-test/t/partition_open_files_limit-master.opt:
Bug#46922: crash when adding partitions and open_files_limit
is reached
New test opt-file for testing when open_files_limit is reached
mysql-test/t/partition_open_files_limit.test:
Bug#46922: crash when adding partitions and open_files_limit
is reached
New test case testing when open_files_limit is reached
sql/ha_partition.cc:
Bug#46922: crash when adding partitions and open_files_limit
is reached
When cleaning up the partitions already locked need to be unlocked,
and not be unlocked/closed after cleaning up.
can lead to bad memory access
Problem: Field_bit is the only field which returns INT_RESULT
and doesn't have unsigned flag. As it's not a descendant of the
Field_num, so using ((Field_num *) field_bit)->unsigned_flag may lead
to unpredictable results.
Fix: check the field type before casting.
mysql-test/r/type_bit.result:
Fix for bug #42803: Field_bit does not have unsigned_flag field,
can lead to bad memory access
- test result.
mysql-test/t/type_bit.test:
Fix for bug #42803: Field_bit does not have unsigned_flag field,
can lead to bad memory access
- test case.
sql/opt_range.cc:
Fix for bug #42803: Field_bit does not have unsigned_flag field,
can lead to bad memory access
- don't cast to (Field_num *) Field_bit, as it's not a Field_num
descendant and is always unsigned by nature.
From revision r5537 to r5636
r5527 is already applied before
Detailed revision comments:
For HotBackup builds we don't want to hide the symbols.
r5537 | vasil | 2009-07-21 04:31:26 -0500 (Tue, 21 Jul 2009) | 5 lines
branches/zip:
Fixups in ChangeLog: sort filenames alphabetically and wrap to 78 chars per
line.
r5539 | vasil | 2009-07-21 05:28:27 -0500 (Tue, 21 Jul 2009) | 4 lines
branches/zip:
Add a test program to check whether the PAUSE instruction is available.
r5625 | vasil | 2009-08-04 00:52:48 -0500 (Tue, 04 Aug 2009) | 32 lines
branches/zip: Merge 5518:5622 from branches/5.1, resolving conflict in r5622
(after resolving the conflict Makefile.am was not changed so I have made
a dummy change so I can commit and thus record that branches/5.1 has been
merged in branches/zip up to 5622):
------------------------------------------------------------------------
r5622 | vasil | 2009-08-03 15:27:00 +0300 (Mon, 03 Aug 2009) | 20 lines
Changed paths:
M /branches/5.1/Makefile.am
branches/5.1:
Merge a change from MySQL:
------------------------------------------------------------
revno: 2988
committer: Satya B <satya.bn@sun.com>
branch nick: mysql-5.1-bugteam
timestamp: Wed 2009-07-01 11:06:05 +0530
message:
Fix build failure after applying Innodb snapshot 5.1-ss5282
After applying Innodb snapshot 5.1-ss5282, build was broken
because of missing header file.
Adding the header file to Makefile.am after informing the
innodb developers.
modified:
storage/innobase/Makefile.am
------------------------------------------------------------------------
r5626 | vasil | 2009-08-04 00:53:31 -0500 (Tue, 04 Aug 2009) | 4 lines
branches/zip:
Revert the dummy change from c5625.
r5629 | marko | 2009-08-04 06:42:44 -0500 (Tue, 04 Aug 2009) | 1 line
branches/zip: mysql-test: Pass MTR's internal checks.
r5635 | marko | 2009-08-05 06:06:55 -0500 (Wed, 05 Aug 2009) | 2 lines
branches/zip: Replace <number> with NUMBER in some comments,
to avoid problems with Doxygen XML output.
r5636 | marko | 2009-08-05 07:27:30 -0500 (Wed, 05 Aug 2009) | 2 lines
branches/zip: lock_rec_validate_page(): Add the parameter zip_size.
This should help track down Mantis Issue #289.
- Remove the "hack" from mtr.pl that skipped searching for the .dll files
when embedded and windows. Now the variables will be preoperly initialized.
- Make the tests detect that they can't run on windows+embedded
