The bug was in the code of the patch fixing bug 698882.
With improper casting the method store_key_field::change_source_field
was called for the elements of the array TABLE_REF::key_copy that
were either of a different type or not allocated at all. This caused
crashes in some queries.
Made sure that the optimal fields are used by TABLE_REF objects
when building index access keys to joined tables.
Fixed a bug in the template function that sorts the elements of
a list using the bubble sort algorithm. The bug caused poor
performance of the function. Also added an optimization that
skips comparison with the most heavy elements that has been
already properly placed in the list.
Made the comparison of the fields belonging to the same Item_equal
more granular: fields belonging to the same table are also ordered
according to some rules.
An assertion failure was triggered for a 6-way join query that used two
join buffers.
The failure happened because every call of JOIN_CACHE::join_matching_records
saved and restored status of all tables that were accessed before the table
join_tab. It must do it only for those of them that follow the last table
using a join buffer.
Applied the fix for bug #47217 from the mysql-6.0 codebase.
The patch adds not null predicates generated for the left parts
of the equality predicates used for ref accesses. This is done
for such predicates both in where conditions and on conditions.
For the where conditions the not null predicates were generated
but in 5.0/5.1 they actually never were used due to some lame
merge from 4.1 to 5.0. The fix for bug #47217 made these
predicates to be used in the condition pushed to the tables.
Yet only this patch generates not null predicates for equality
predicated from on conditions of outer joins.
This patch introduces a performance regression that can be
observed on a test case from null_key.test. The regression
will disappear after the fix for bug #57024 from mariadb-5.1
is pulled into mariadb-5.3.
The patch contains many changes in the outputs of the EXPLAIN
commands since generated not null predicates are considered as
parts of the conditions pushed to join tables and may add
'Usingwhere' in some rows of EXPLAINs where there used
to be no such comments.
file .\filesort.cc, line 149 (part II)
Problem: the server didn't disregard sort order
for some zero length tuples.
Fix: skip sort order in such a case
(zero length NOT NULL string functions).
mysql-test/r/select.result:
Fix for bug #54459: Assertion failed: param.sort_length,
file .\filesort.cc, line 149 (part II)
- test result.
mysql-test/t/select.test:
Fix for bug #54459: Assertion failed: param.sort_length,
file .\filesort.cc, line 149 (part II)
- test case.
sql/sql_select.cc:
Fix for bug #54459: Assertion failed: param.sort_length,
file .\filesort.cc, line 149 (part II)
- disregard sort order for zero length NOT NULL string functions
along with zero length NOT NULL fields.
Item_field::print method does not take into
account fields whose values may be null.
The fix is to print 'NULL' if field value is null.
mysql-test/r/explain.result:
test case
mysql-test/r/func_str.result:
result fix
mysql-test/r/having.result:
result fix
mysql-test/r/select.result:
result fix
mysql-test/r/subselect.result:
result fix
mysql-test/r/union.result:
result fix
mysql-test/t/explain.test:
test case
sql/item.cc:
print 'NULL' if field value is null.
column is used for ORDER BY
Problem: filesort isn't meant for null length sort data
(e.g. char(0)), that leads to a server crash.
Fix: disregard sort order if sort data record length is 0 (nothing
to sort).
mysql-test/r/select.result:
Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL
column is used for ORDER BY
- test result.
mysql-test/t/select.test:
Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL
column is used for ORDER BY
- test case.
sql/filesort.cc:
Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL
column is used for ORDER BY
- assert added as filesort cannot handle null length sort data.
sql/sql_select.cc:
Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL
column is used for ORDER BY
- don't sort null length data e.g. in case of ORDER BY CHAR(0).
- Marked a couple of tests with --big
- Fixed xtradb/handler/ha_innodb.cc to call explain_filename()
storage/xtradb/handler/ha_innodb.cc:
Call explain_filename() to get proper names for partitioned tables
NULLable BIGINT and INT columns in comparison
Problem: a consequence of the fix for 43668.
Some Arg_comparator inner initialization missed,
that may lead to unpredictable (wrong) comparison
results.
Fix: always properly initialize Arg_comparator
before its usage.
mysql-test/r/select.result:
Fix for bug#49517: Inconsistent behavior while using
NULLable BIGINT and INT columns in comparison
-test result.
mysql-test/t/select.test:
Fix for bug#49517: Inconsistent behavior while using
NULLable BIGINT and INT columns in comparison
-test case.
sql/item_cmpfunc.cc:
Fix for bug#49517: Inconsistent behavior while using
NULLable BIGINT and INT columns in comparison
- now all Arg_comparator::set_cmp_func() set
Arg_comparator::set_null to ensure its proper initialization
in all cases (by default it's set to TRUE in constructors).
sql/item_cmpfunc.h:
Fix for bug#49517: Inconsistent behavior while using
NULLable BIGINT and INT columns in comparison
- now all Arg_comparator::set_cmp_func() set
Arg_comparator::set_null to ensure its proper initialization
in all cases (by default it's set to TRUE in constructors).
WL#2474 "Multi Range Read: Change the default MRR implementation to implement new MRR interface"
WL#2475 "Batched range read functions for MyISAM/InnoDb"
"Index condition pushdown for MyISAM/InnoDB"
Igor's fix from sp1r-igor@olga.mysql.com-20080330055902-07614:
There could be observed the following problems:
1. EXPLAIN did not mention pushdown conditions from on expressions in the
'extra' column. As a result if a query had no where conditions pushed
down to a table, but had on conditions pushed to this table the 'extra'
column in the EXPLAIN for the table missed 'using where'.
2. Conditions for ref access were not eliminated from on expressions
though such conditions were eliminated from the where condition.
Arg_comparator uses Item_cache objects to store constants being compared when
they're need a type conversion. Because this cache wasn't initialized properly
Arg_comparator might produce wrong comparison result.
The Arg_comparator::cache_converted_constant function now initializes cache
prior to usage.
mysql-test/r/select.result:
Added a test case for he bug#49489.
mysql-test/t/select.test:
Added a test case for he bug#49489.
sql/item_cmpfunc.cc:
Bug#49489: Uninitialized cache led to a wrong result.
The Arg_comparator::cache_converted_constant function now initializes cache
prior to usage.
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.
- Moved some code from innodb_plugin to xtradb, to ensure that all tests runs
- Did changes in pbxt and maria storage engines becasue of changes in thd->query
- Reverted wrong code in sql_table.cc for how ROW_FORMAT is used.
This is a re-commit of Monty's merge to eliminate an extra commit from
MySQL-5.1.42 that was accidentally included in the merge.
This is a merge of the MySQL 5.1.41 clone-off (clone-5.1.41-build). In
case there are any extra changes done before final MySQL 5.1.41
release, these will need to be merged later before MariaDB 5.1.41
release.
init_read_record() - (records.cc:274)
Item_cond::used_tables_cache was accessed in
records.cc#init_read_record() without being initialized. It had
not been initialized because it was wrongly assumed that the
Item's variables would not be accessed, and hence
quick_fix_field() was used instead of fix_fields() to save a few
CPU cycles at creation time.
The fix is to properly initilize the Item by replacing
quick_fix_field() with fix_fields().
mysql-test/r/select.result:
Add test for BUG#48052
mysql-test/t/select.test:
Add test for BUG#48052
sql/sql_select.cc:
Properly initialize Item_cond_and by calling fix_fields (instead of quick_fix_field) when the Item that "ANDs" WHERE clause conditions with HAVING clause conditions is created.
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.
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.
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).
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.
mysql-test/r/select.result:
A test case for the bug#45266: Uninitialized variable lead to an empty result.
mysql-test/t/select.test:
A test case for the bug#45266: Uninitialized variable lead to an empty result.
sql/sql_base.cc:
Bug#45266: Uninitialized variable lead to an empty result.
The open_table function now initializes the TABLE::reginfo.impossible_range
variable.
sql/sql_select.cc:
Bug#45266: Uninitialized variable lead to an empty result.
The open_table function now initializes the TABLE::reginfo.impossible_range
variable.
sql/structs.h:
Bug#45266: Uninitialized variable lead to an empty result.
A comment is added.
Bug #40925: Equality propagation takes non indexed attribute
Query execution plans and execution time of queries like
select a, b, c from t1
where a > '2008-11-21' and b = a limit 10
depended on the order of equality operator parameters:
"b = a" and "a = b" are not same.
An equality propagation algorithm has been fixed:
the substitute_for_best_equal_field function should not
substitute a field for an equal field if both fields belong
to the same table.
mysql-test/r/select.result:
Added test case for bug #40925.
mysql-test/t/select.test:
Added test case for bug #40925.
sql/item.cc:
Bug #40925: Equality propagation takes non indexed attribute
An equality propagation algorithm has been fixed:
the substitute_for_best_equal_field function should not
substitute a field for an equal field if both fields belong
to the same table.
select where .. (col=col and col=col) or ... (false expression)
Problem: optimizer didn't take into account a singular case
when we eliminated all the predicates at the AND level of WHERE.
That may lead to wrong results.
Fix: replace (a=a AND a=a...) with TRUE if we eliminated all the
predicates.
mysql-test/r/select.result:
Fix for bug #42957: no results from
select where .. (col=col and col=col) or ... (false expression)
- test result.
mysql-test/t/select.test:
Fix for bug #42957: no results from
select where .. (col=col and col=col) or ... (false expression)
- test case.
sql/sql_select.cc:
Fix for bug #42957: no results from
select where .. (col=col and col=col) or ... (false expression)
- replacing equality predicates by multiple equality items check
if we eliminate all the predicates at the AND level and
replace them with TRUE if so.
Various parts of code used different 'precision' arguments for sprintf("%g") when converting
floating point numbers to a string. This led to differences in results in some cases
depending on whether the text-based or prepared statements protocol is used for a query.
Fixed by changing arguments to sprintf("%g") to always be 15 (DBL_DIG) so that results are
consistent regardless of the protocol.
This patch will be null-merged to 6.0 as the problem does not exists there (fixed by the
patch for WL#2934).
client/sql_string.cc:
Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
libmysql/libmysql.c:
Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
mysql-test/r/archive_gis.result:
Fixed test results to take additional precision into account.
mysql-test/r/func_group.result:
Fixed test results to take additional precision into account.
mysql-test/r/func_math.result:
Fixed test results to take additional precision into account.
mysql-test/r/func_str.result:
Fixed test results to take additional precision into account.
mysql-test/r/gis.result:
Fixed test results to take additional precision into account.
mysql-test/r/innodb_gis.result:
Fixed test results to take additional precision into account.
mysql-test/r/select.result:
Fixed test results to take additional precision into account.
mysql-test/r/sp.result:
Fixed test results to take additional precision into account.
mysql-test/r/type_float.result:
Fixed test results to take additional precision into account.
mysql-test/t/type_float.test:
Fixed test results to take additional precision into account.
sql/sql_string.cc:
Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
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
Field_varstring::store
The code that temporary saved the bitmaps of the read set and the write set so that
it can set it to all columns for debug purposes was not expecting that the
table->read_set and table->write_set can be the same. And was always saving both in
sequence.
As a result the original value was never restored.
Fixed by saving & restoring the original value only once if the two sets are the
same (in a special set of functions).
mysql-test/r/select.result:
Bug #37936: test case
mysql-test/t/select.test:
Bug #37936: test case
sql/item_cmpfunc.cc:
Bug #37936: don't save/restore twice if the read and write sets are the same
sql/opt_range.cc:
Bug #37936: don't save/restore twice if the read and write sets are the same
sql/table.h:
Bug #37936: Make a designated set of functions that save/restore
both the read and the write sets in a single call.
into kaamos.(none):/data/src/opt/mysql-5.1-opt
client/mysql.cc:
Auto merged
client/mysqldump.c:
Auto merged
configure.in:
Auto merged
include/my_global.h:
Auto merged
libmysql/libmysql.c:
Auto merged
libmysqld/lib_sql.cc:
Auto merged
mysql-test/include/mix1.inc:
Auto merged
mysql-test/r/create.result:
Auto merged
mysql-test/r/func_str.result:
Auto merged
mysql-test/r/innodb.result:
Auto merged
mysql-test/r/innodb_mysql.result:
Auto merged
mysql-test/r/select.result:
Auto merged
mysql-test/r/subselect.result:
Auto merged
mysql-test/t/create.test:
Auto merged
mysql-test/t/disabled.def:
Auto merged
sql/filesort.cc:
Auto merged
sql/handler.cc:
Auto merged
sql/item.cc:
Auto merged
sql/item.h:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_func.h:
Auto merged
sql/item_sum.cc:
Auto merged
sql/log.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/sp.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_plugin.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
storage/ndb/src/kernel/blocks/backup/Backup.hpp:
Auto merged
tests/mysql_client_test.c:
Auto merged
mysql-test/r/func_time.result:
Manual merge.
mysql-test/r/view.result:
Manual merge.
mysql-test/t/view.test:
Manual merge.
scripts/mysql_config.sh:
Manual merge.
sql-common/client.c:
Manual merge.
sql/sql_parse.cc:
Manual merge.
