Bug #25000 myisam.test fails on 'pb-valgrind-*' Valgrind
- Move tests that need symlink to symlink.test
mysql-test/r/myisam.result:
- Move tests that need symlink to symlink.test
mysql-test/r/symlink.result:
- Move tests that need symlink to symlink.test
mysql-test/t/myisam.test:
- Move tests that need symlink to symlink.test
mysql-test/t/symlink.test:
- Move tests that need symlink to symlink.test
into pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint
mysys/my_read.c:
Auto merged
scripts/make_binary_distribution.sh:
Auto merged
sql/field.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_parse.cc:
Auto merged
into pilot.mysql.com:/home/msvensson/mysql/mysql-4.1-maint
mysql-test/t/mysqladmin.test:
Auto merged
mysys/mf_iocache.c:
Auto merged
mysys/my_read.c:
Auto merged
mysys/my_seek.c:
Auto merged
sql/sql_parse.cc:
Auto merged
mysql-test/t/backup.test:
Backport a patch for sporadically failing myisam.test (and now ps.test)
from 5.0. The cause was in backup.test not cleaning up tables in
mysqltest-vardir/tmp after itself.
mysql-test/t/ps.test:
Add additional protection against possible failure in the middle of
backup.test
into olga.mysql.com:/home/igor/mysql-5.0-opt
mysql-test/r/range.result:
Auto merged
mysql-test/t/range.test:
Auto merged
sql/opt_range.h:
Manual merge.
The optimizer needs to evaluate whether predicates are better
evaluated using an index. IN is one such predicate.
To qualify an IN predicate must involve a field of the index
on the left and constant arguments on the right.
However whether an expression is a constant can be determined only
by knowing the preceding tables in the join order.
Assuming that only IN predicates with expressions on the right that
are constant for the whole query qualify limits the scope of
possible optimizations of the IN predicate (more specifically it
doesn't allow the "Range checked for each record" optimization for
such an IN predicate.
Fixed by not pre-determining the optimizability of the IN predicate
in the case when all right IN operands are not SQL constant expressions
mysql-test/r/func_in.result:
BUG#20420: optimizer reports wrong keys on left join with IN
- test case
mysql-test/t/func_in.test:
BUG#20420: optimizer reports wrong keys on left join with IN
- test case
sql/item_cmpfunc.h:
BUG#20420: optimizer reports wrong keys on left join with IN
- cannot decide on the optimizability of a function without
knowing the tables before it in the join order
mysql-test/r/sp.result:
Auto merged
mysql-test/t/sp.test:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_list.h:
Auto merged
sql/sql_show.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
into bodhi.local:/opt/local/work/mysql-4.1-4968-to-push
sql/mysql_priv.h:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_parse.cc:
Manual merge.
sql/sql_table.cc:
Manual merge.
of untouched rows in full table scans".
SELECT ... FOR UPDATE/LOCK IN SHARE MODE statements as well as
UPDATE/DELETE statements which were executed using full table
scan were not releasing locks on rows which didn't satisfy
WHERE condition.
This bug surfaced in 5.0 and affected NDB tables. (InnoDB tables
intentionally don't support such unlocking in default mode).
This problem occured because code implementing join didn't call
handler::unlock_row() for rows which didn't satisfy part of condition
attached to this particular table/level of nested loop. So we solve
the problem adding this call.
Note that we already had this call in place in 4.1 but it was lost
(actually not quite correctly placed) when we have introduced nested
joins.
Also note that additional QA should be requested once this patch is
pushed as interaction between handler::unlock_row() and many recent
MySQL features such as subqueries, unions, views is not tested enough.
mysql-test/r/ndb_lock.result:
Enabled back part of the test that covers bug #20390 "SELECT FOR
UPDATE does not release locks of untouched rows in full table scans".
Adjusted test in such way that it now covers both execution paths
in which we unlock non-matching rows inspected during table scan.
mysql-test/t/ndb_lock.test:
Enabled back part of the test that covers bug #20390 "SELECT FOR
UPDATE does not release locks of untouched rows in full table scans".
Adjusted test in such way that it now covers both execution paths
in which we unlock non-matching rows inspected during table scan.
sql/sql_select.cc:
evaluate_join_record() should call handler::unlock_row() for records
which don't satisfy condition which was pushed-down to this table/level
of nested loop.
We just put back the thing that we already have in 4.1 and which was lost
when we have introduced nested joins.
for queries using 'range checked for each record'.
The problem was fixed in 5.0 by the patch for bug 12291.
This patch down-ported the corresponding code from 5.0 into
QUICK_SELECT::init() and added a new test case.
mysql-test/r/range.result:
Added a test case for bug #24776.
mysql-test/t/range.test:
Added a test case for bug #24776.
sql/opt_range.h:
Fixed bug #24776: an assertion abort in handler::ha_index_init
for queries using 'range checked for each record'.
The problem was fixed in 5.0 by the patch for bug 12291.
The patch for 4.1 down-ported the corresponding code from 5.0 into
QUICK_SELECT::init().
in a select list.
The objects of the Item_trigger_field class inherited the implementations
of the methods copy_or_same, get_tmp_table_item and get_tmp_table_field
from the class Item_field while they rather should have used the default
implementations defined for the base class Item.
It could cause catastrophic problems for triggers that used SELECTs
with select list containing trigger fields such as NEW.<table column>
under DISTINCT.
mysql-test/r/trigger.result:
Added a test case for bug #25398.
mysql-test/t/trigger.test:
Added a test case for bug #25398.
- Make the code produce correct result: use an array of triggers to turn on/off equalities for each
compared column. Also turn on/off optimizations based on those equalities.
- Make EXPLAIN output show "Full scan on NULL key" for tables for which we switch between
ref/unique_subquery/index_subquery and ALL access.
- index_subquery engine now has HAVING clause when it is needed, and it is
displayed in EXPLAIN EXTENDED
- Fix incorrect presense of "Using index" for index/unique-based subqueries (BUG#22930)
// bk trigger note: this commit refers to BUG#24127
mysql-test/r/ndb_subquery.result:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- Updated test results (checked)
mysql-test/r/subselect.result:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- Updated test results (checked)
mysql-test/r/subselect2.result:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- Updated test results (checked)
mysql-test/r/subselect3.result:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- Testcases
mysql-test/t/subselect3.test:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- Testcases
sql/item_cmpfunc.cc:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- For row-based IN subqueries, use one flag per each column. Set the flags appropriately before
running the subquery.
sql/item_cmpfunc.h:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- Added Item_func_trig_cond::get_triv_var()
sql/item_subselect.cc:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- Item_subselect::exec() and subselect_*_engine::exec() don't have parameter
anymore - now Item_subselect owns the pushed down predicates guard flags.
- A correct set of conditional predicates is now pushed into row-based IN
subquery.
- select_indexsubquery_engine now has "HAVING clause" (needed for correct query
results), and it is shown in EXPLAIN EXTENDED
sql/item_subselect.h:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- Item_subselect::exec() and subselect_*_engine::exec() don't have parameter
anymore - now Item_subselect owns the pushed down predicates guard flags.
- A correct set of conditional predicates is now pushed into row-based IN
subquery.
- select_indexsubquery_engine now has "HAVING clause" (needed for correct query
results), and it is shown in EXPLAIN EXTENDED
sql/mysql_priv.h:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- Added "in_having_cond" special Item name
sql/mysqld.cc:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- Added "in_having_cond" special Item name
sql/sql_lex.h:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
sql/sql_select.cc:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- Make "ref" analyzer be able to work with conditional equalities
- Fix subquery optimization code to match the changes in what kinds of
conditions are pushed down into subqueries
- Fix wrong EXPLAIN output in some queries with subquery (BUG#22390)
sql/sql_select.h:
BUG#24127: wrong result for (null,not-null) IN (SELECT a,b ...)
- Make "ref" analyzer be able to work with conditional equalities
- Fix wrong EXPLAIN output in some queries with subquery (BUG#22390)
When transforming "oe IN (SELECT ie ...)" wrap the pushed-down predicates
iff "oe can be null", not "ie can be null".
The fix doesn't cover row-based subqueries, those will be fixed in #24127.
mysql-test/r/subselect.result:
BUG#24085: Wrong result for NULL IN (SELECT not_null_val FROM ...)
Update the test results (checked)
mysql-test/r/subselect3.result:
BUG#24085: Wrong result for NULL IN (SELECT not_null_val FROM ...)
- Testcase
mysql-test/t/subselect3.test:
BUG#24085: Wrong result for NULL IN (SELECT not_null_val FROM ...)
- Testcase
sql/item_subselect.cc:
BUG#24085: Wrong result for NULL IN (SELECT not_null_val FROM ...)
When transforming "oe IN (SELECT ie ...)" we should make special
provisions (wrap the pushed predicates) if we can encounter
NULL IN (SELECT ...), i.e. when oe->maybe_null. The code was checking
for ie->maybe_null instead, fixed it for single value based subqueries.
Row-based subqueries (e.g. (a,b) IN (SELECT c,d ...)) are not fixed
because they won't produce correct results for several other reasons
(filed as #24085)
into moonbone.local:/work/latest-5.0-opt-mysql
mysql-test/t/func_str.test:
Auto merged
sql/item_strfunc.cc:
Auto merged
sql/item_strfunc.h:
Auto merged
sql/sql_delete.cc:
Auto merged
mysql-test/r/delete.result:
Manual merge
mysql-test/r/func_str.result:
Manual merge
mysql-test/t/delete.test:
Manual merge
into mysql.com:/nfsdisk1/lars/MERGE/mysql-5.0-merge
client/mysqlbinlog.cc:
Auto merged
client/mysqldump.c:
Auto merged
include/my_pthread.h:
Auto merged
mysql-test/t/disabled.def:
Auto merged
mysys/my_thr_init.c:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/log.cc:
Auto merged
sql/log_event.cc:
Auto merged
sql/log_event.h:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/set_var.cc:
Auto merged
sql/set_var.h:
Auto merged
sql/sp_head.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_locale.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
Currently in the ONLY_FULL_GROUP_BY mode no hidden fields are allowed in the
select list. To ensure this each expression in the select list is checked
to be a constant, an aggregate function or to occur in the GROUP BY list.
The last two requirements are wrong and doesn't allow valid expressions like
"MAX(b) - MIN(b)" or "a + 1" in a query with grouping by a.
The correct check implemented by the patch will ensure that:
any field reference in the [sub]expressions of the select list
is under an aggregate function or
is mentioned as member of the group list or
is an outer reference or
is part of the select list element that coincide with a grouping element.
The Item_field objects now can contain the position of the select list
expression which they belong to. The position is saved during the
field's Item_field::fix_fields() call.
The non_agg_fields list for non-aggregated fields is added to the SELECT_LEX
class. The SELECT_LEX::cur_pos_in_select_list now contains the position in the
select list of the expression being currently fixed.
sql/item.cc:
Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
The Item_field objects now contain the position of the select list
expression which they belong to. The position is saved at the field's
Item_field::fix_fields() call.
sql/item.h:
Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
The Item_field objects now can store the position in the select list of the
expression to which they are belongs to.
sql/mysql_priv.h:
Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
Added the UNDEF_POS constant.
sql/sql_base.cc:
Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
Now the setup_fields() function maintains the cur_pos_in_select_list variable.
sql/sql_lex.cc:
Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
Set the cur_pos_in_select_list variable and the non_agg_fields list to their initial state.
sql/sql_lex.h:
Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
The non_agg_fields list for non-aggregated fields is added to the SELECT_LEX
class. The SELECT_LEX::cur_pos_in_select_list now stores the position in the
select list of the expression being currently fixed.
sql/sql_select.cc:
Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
Each select now keeps the list of fields that aren't
used under any aggregate function. If an expression from the select list
isn't found in the GROUP BY list the setup_group() function additionally
checks whether non-aggregated fields occur in that expression.
If there at least one such field and it isn't found in the GROUP BY list
then an error is thrown.
sql/sql_union.cc:
Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
Clean up of the non_agg_fields list.
mysql-test/r/group_by.result:
Added a test case for the bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
mysql-test/t/group_by.test:
Added a test case for the bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
into bodhi.local:/opt/local/work/mysql-5.0-runtime
heap/hp_block.c:
Auto merged
mysql-test/r/view.result:
Auto merged
server-tools/instance-manager/listener.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/sp_head.cc:
Auto merged
sql/sp_head.h:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_prepare.cc:
Auto merged
sql/sql_string.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
tests/mysql_client_test.c:
Auto merged
heap/hp_write.c:
SCCS merged
aliases ignored
When a column reference to a column in JOIN USING is resolved and a new
Item is created for this column the user defined name was lost.
This fix preserves the alias by setting the name of the new Item to the
original alias.
mysql-test/r/join.result:
BUG#25106: A USING clause in combination with a VIEW results in column
aliases ignored
- test case
mysql-test/t/join.test:
BUG#25106: A USING clause in combination with a VIEW results in column
aliases ignored
- test case
sql/sql_base.cc:
BUG#25106: A USING clause in combination with a VIEW results in column
aliases ignored
- take the alias of the Item to be replaced and set it into the newly
allocated Item.
into bk-internal.mysql.com:/data0/bk/mysql-5.0-marvel
libmysqld/lib_sql.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_strfunc.cc:
Auto merged
sql/mysqld.cc:
Auto merged
sql/sql_prepare.cc:
Auto merged
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint
include/my_global.h:
Auto merged
mysql-test/Makefile.am:
Auto merged
mysql-test/lib/mtr_cases.pl:
Auto merged
mysql-test/lib/mtr_process.pl:
Auto merged
mysql-test/mysql-test-run.pl:
Auto merged
mysql-test/t/myisam.test:
Auto merged
mysql-test/t/mysqladmin.test:
Auto merged
mysql-test/t/rpl_rotate_logs.test:
Auto merged
scripts/make_binary_distribution.sh:
Auto merged
scripts/mysqlbug.sh:
Auto merged
sql/field.cc:
Auto merged
sql/field.h:
Auto merged
sql/item_sum.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/opt_range.cc:
Auto merged
sql/sql_class.h:
Auto merged
Makefile.am:
manual merge
mysql-test/t/trigger.test:
manual merge
strings/ctype-extra.c:
manual merge
correctly.
The Item_func::print method was used to print the Item_func_encode and the
Item_func_decode objects. The last argument to ENCODE and DECODE functions
is a plain C string and thus Item_func::print wasn't able to print it.
The print() method is added to the Item_func_encode class. It correctly
prints the Item_func_encode and the Item_func_decode objects.
mysql-test/t/func_str.test:
Added a test case for bug#23409: Arguments of the ENCODE() and the
> DECODE() functionswere not printed correctly.
mysql-test/r/func_str.result:
Added a test case for bug#23409: Arguments of the ENCODE() and the DECODE() functions were not printed correctly.
sql/item_strfunc.h:
Bug#23409: Arguments of the ENCODE() and the DECODE() functions were not printed correctly.
The print() method is added to the Item_func_encode class.
sql/item_strfunc.cc:
Bug#23409: Arguments of the ENCODE() and the DECODE() functions were not printed correctly.
The print() method is added to the Item_func_encode class. It correctly
prints the Item_func_encode and the Item_func_decode objects.
WHERE is present.
If a DELETE statement with ORDER BY and LIMIT contains a WHERE clause
with conditions that for sure cannot be used for index access (like in
WHERE @var:= field) the execution always follows the filesort path.
It happens currently even when for the above case there is an index that
can be used to speedup sorting by the order by list.
Now if a DELETE statement with ORDER BY and LIMIT contains such WHERE
clause conditions that cannot be used to build any quick select then
the mysql_delete() tries to use an index like there is no WHERE clause at all.
mysql-test/t/delete.test:
Added a test case for bug#17711: DELETE doesn't use index when ORDER BY, LIMIT and non-restricting
WHERE is present.
mysql-test/r/delete.result:
Added a test case for bug#17711: DELETE doesn't use index when ORDER BY, LIMIT and non-restricting WHERE is present.
sql/sql_delete.cc:
Bug#17711: DELETE doesn't use index when ORDER BY, LIMIT and non-restricting WHERE is present.
Now if a DELETE statement with ORDER BY and LIMIT contains such WHERE
clause conditions that cannot be used to build any quick select then
the mysql_delete() tries to use an index like there is no WHERE clause at all.
into tiger.mmj.dk:/Users/mmj/bktrees/mysql-5.0
configure.in:
Auto merged
mysql-test/install_test_db.sh:
Auto merged
mysql-test/mysql-test-run.pl:
Auto merged
scripts/mysql_install_db.sh:
Auto merged
sql/CMakeLists.txt:
Auto merged
sql/mysqld.cc:
Auto merged
win/configure.js:
Auto merged
mysql-test/r/wait_timeout.result:
Added two possible error cases for a test. Depending
on a platform, either errno can occur and is correct.
Possible errors are CR_SERVER_GONE_ERROR and
CR_SERVER_LOST
mysql-test/t/wait_timeout.test:
Added two possible error cases for a test. Depending
on a platform, either errno can occur and is correct.
Possible errors are CR_SERVER_GONE_ERROR and
CR_SERVER_LOST
In the method Item_field::fix_fields we try to resolve the name of
the field against the names of the aliases that occur in the select
list. This is done by a call of the function find_item_in_list.
When this function finds several occurrences of the field name
it sends an error message to the error queue and returns 0.
Yet the code did not take into account that find_item_in_list
could return 0 and tried to dereference the returned value.
mysql-test/r/order_by.result:
Added a test case for bug #25427.
mysql-test/t/order_by.test:
Added a test case for bug #25427.
sql/item.cc:
Fixed bug #25427.
In the method Item_field::fix_fields we try to resolve the name of
the field against the names of the aliases that occur in the select
list. This is done by a call of the function find_item_in_list.
When this function finds several occurrences of the field name
it sends an error message to the error queue and returns 0.
Yet the code did not take into account that find_item_in_list
could return 0 and tried to dereference the returned value.
