The problem occurred when one had a subquery that had an equality X=Y where
Y referred to a named select list expression from the parent select. MySQL
crashed when trying to use the X=Y equality for ref-based access.
Fixed by allowing non-Item_field items in the described case.
mysql-test/r/subselect.result:
BUG#33794 "MySQL crashes executing specific query"
- Testcase
mysql-test/t/subselect.test:
BUG#33794 "MySQL crashes executing specific query"
- Testcase
sql/sql_select.cc:
BUG#33794 "MySQL crashes executing specific query"
get_store_key() assumed that if it got a reference
t.key=Item_outer_ref(Item_direct_ref(x))
then x was an Item_field object, which is not the case when one refers to a
named select list expression out ot subquery.
into linux-st28.site:/home/martin/mysql/src/bug32848/my50-bug32848
sql/field.cc:
Auto merged
sql/field.h:
Auto merged
sql/item.cc:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/r/union.result:
Bug#32848: Manual merge
mysql-test/t/union.test:
Bug#32848: Manual merge
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
client/mysql.cc:
Auto merged
client/mysqltest.c:
Auto merged
include/mysql_com.h:
Auto merged
libmysql/CMakeLists.txt:
Auto merged
myisam/mi_check.c:
Auto merged
mysql-test/r/delayed.result:
Auto merged
mysql-test/r/innodb.result:
Auto merged
mysql-test/r/myisam.result:
Auto merged
mysql-test/r/ps.result:
Auto merged
mysql-test/t/merge.test:
Auto merged
mysql-test/t/myisam.test:
Auto merged
mysql-test/t/subselect.test:
Auto merged
mysql-test/t/type_datetime.test:
Auto merged
mysql-test/t/variables.test:
Auto merged
sql/field.cc:
Auto merged
sql/ha_myisam.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/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/opt_range.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/set_var.h:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
mysql-test/r/func_misc.result:
manual merge
mysql-test/r/innodb_mysql.result:
manual merge
mysql-test/t/func_misc.test:
manual merge
mysql-test/t/innodb_mysql.test:
manual merge
sql/sql_insert.cc:
manual merge
There were two problems when inferring the correct field types resulting from
UNION queries.
- If the type is NULL for all corresponding fields in the UNION, the resulting
type would be NULL, while the type is BINARY(0) if there is just a single
SELECT NULL.
- If one SELECT in the UNION uses a subselect, a temporary table is created
to represent the subselect, and the result type defaults to a STRING type,
hiding the fact that the type was unknown(just a NULL value).
Fixed by remembering whenever a field was created from a NULL value and pass
type NULL to the type coercion if that is the case, and creating a string field
as result of UNION only if the type would otherwise be NULL.
mysql-test/r/union.result:
Bug#32848: Test result
mysql-test/t/union.test:
Bug#32848: Test case
sql/field.cc:
Bug#32848: Initialization of new field
sql/field.h:
Bug#32848: New member to record when a field was created from a NULL value.
sql/item.cc:
Bug#32848:
A field created from a NULL value will submit NULL as type to the
type coercion procedure.
If Item_type_holder has not inferred the correct type after processing all
SELECTs in a UNION, a string field is created.
sql/sql_select.cc:
Bug#32848: Recording when a field is created from a NULL value.
The index (key_part_1, key_part-2) was erroneously considered as compatible
with the required ordering in the function test_test_if_order_by_key when
a query with an ORDER BY clause contained a condition of the form
key_part_1=const OR key_part_1 IS NULL
and the order list contained only key_part_2. This happened because the value
of the const_key_parts field in the KEYUSE structure was not formed correctly
for the keys that could be used for ref_or_null access.
This was fixed in the code of the update_ref_and_keys function.
The problem could not manifest itself for MyISAM databases because the
implementation of the keys_to_use_for_scanning() handler function always
returns an empty bitmap for the MyISAM engine.
mysql-test/r/innodb_mysql.result:
Added a test case for bug #32815.
mysql-test/t/innodb_mysql.test:
Added a test case for bug #32815.
sql/sql_select.cc:
Fixed bug #32815.
The index (key_part_1, key_part-2) was erroneously considered as compatible
with the required ordering in the function test_test_if_order_by_key when
a query with an ORDER BY clause contained a condition of the form
key_part_1=const OR key_part_1 IS NULL
and the order list contained only key_part_2. This happened because the value
of the const_key_parts field in the KEYUSE structure was not formed correctly
for the keys that could be used for ref_or_null access.
This was fixed in the code of the update_ref_and_keys function.
into ramayana.hindu.god:/home/tsmith/m/bk/maint/50
client/mysqldump.c:
Auto merged
include/my_sys.h:
Auto merged
libmysql/CMakeLists.txt:
Auto merged
libmysql/Makefile.shared:
Auto merged
myisam/ft_boolean_search.c:
Auto merged
myisam/sort.c:
Auto merged
mysql-test/t/cast.test:
Auto merged
mysql-test/t/variables.test:
Auto merged
sql/field.cc:
Auto merged
sql/ha_myisam.cc:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_cmpfunc.h:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/opt_range.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/set_var.h:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_table.cc:
Auto merged
mysql-test/mysql-test-run.pl:
Manual merge
mysql-test/r/ctype_ucs.result:
Manual merge
mysql-test/r/func_misc.result:
Manual merge
mysql-test/t/binlog_killed.test:
Manual merge
mysql-test/t/ctype_ucs.test:
Manual merge
mysql-test/t/func_misc.test:
Manual merge
sql/item_strfunc.h:
Manual merge
strings/ctype-simple.c:
Manual merge
into magare.gmz:/home/kgeorge/mysql/autopush/B30788-5.0-opt
sql/item.h:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/r/subselect.result:
merge of 5.0-opt
mysql-test/t/subselect.test:
merge of 5.0-opt
Index lookup does not always guarantee that we can
simply remove the relevant conditions from the WHERE
clause. Reasons can be e.g. conversion errors,
partial indexes etc.
The optimizer was removing these parts of the WHERE
condition without any further checking.
This leads to "false positives" when using indexes.
Fixed by checking the index reference conditions
(using WHERE) when using indexes with sub-queries.
mysql-test/r/subselect.result:
Bug #30788:
- using where
- test case
mysql-test/r/subselect3.result:
Bug #30788: using where
mysql-test/t/subselect.test:
Bug #30788: test case
sql/item.h:
Bug #30788:
- Declare eq() method of Item_cache descendants : this is used in
test_if_ref()
- preserve the field that is being cached for type comparisions
sql/sql_select.cc:
Bug #30788: Don't remove the WHERE when using index lookup
with subqueries.
Loose index scan does the grouping so the temp table does
not need to do it, even when sorting.
Fixed by checking if the grouping is already done before
doing sorting and grouping in a temp table and do only
sorting.
mysql-test/r/group_min_max.result:
Bug #32268: test case
mysql-test/t/group_min_max.test:
Bug #32268: test case
sql/sql_select.cc:
Bug #32268: don't group in the temp table if already done
Server failed in assert() when we tried to create a DECIMAL() temp field
with a scale of more than the allowed 30. Now we limit the scale to the
allowed maximum. A truncation warning is thrown as necessary.
mysql-test/r/type_newdecimal.result:
Show that out of range DECIMAL temp fields will no longer
stop the server with an assert.
mysql-test/t/type_newdecimal.test:
Show that out of range DECIMAL temp fields will no longer
stop the server with an assert.
sql/sql_select.cc:
When creating DECIMAL() temp field, ascertain we stay within allowed
limits. If not, truncate and warn.
checked for each record'
The problem was in incorrectly calculated length of the buffer used to
store a hexadecimal representation of an index map in
select_describe(). This could result in buffer overrun and stack
corruption under some circumstances.
Fixed by correcting the calculation.
mysql-test/r/explain.result:
Added a test case for bug #32241.
mysql-test/t/explain.test:
Added a test case for bug #32241.
sql/sql_select.cc:
Corrected the buffer length calculation. Count one hex digit as 4 bits,
not 8.
The columns in HAVING can reference the GROUP BY and
SELECT columns. There can be "table" prefixes when
referencing these columns. And these "table" prefixes
in HAVING use the table alias if available.
This means that table aliases are subject to the same
storage rules as table names and are dependent on
lower_case_table_names in the same way as the table
names are.
Fixed by :
1. Treating table aliases as table names
and make them lowercase when printing out the SQL
statement for view persistence.
2. Using case insensitive comparison for table
aliases when requested by lower_case_table_names
mysql-test/r/lowercase_view.result:
Bug #31562: test case
mysql-test/t/lowercase_view.test:
Bug #31562: test case
sql/item.cc:
Bug #31562: lower_case_table_name contious comparison
when searching in GROUP BY
sql/sql_base.cc:
Bug #31562: lower_case_table_name contious comparison
when searching in SELECT
sql/sql_select.cc:
Bug #31562: treat table aliases as table names
and make them lowercase when printing
UNIQUE (eq-ref) lookups result in table being considered as a "constant" table.
Queries that consist of only constant tables are processed in do_select() in a
special way that doesn't invoke evaluate_join_record(), and therefore doesn't
increase the counters join->examined_rows and join->thd->row_count.
The patch increases these counters in this special case.
NOTICE:
This behavior seems to contradict what the documentation says in Sect. 5.11.4:
"Queries handled by the query cache are not added to the slow query log, nor
are queries that would not benefit from the presence of an index because the
table has zero rows or one row."
No test case in 5.0 as issue shows only in slow query log, and other counters
can give subtly different values (with regard to counting in create_sort_index(),
synthetic rows in ROLLUP, etc.).
sql/sql_class.h:
add documentation for some variables
sql/sql_select.cc:
Don't forget const tables when counting read records!
The bug is a regression introduced by the fix for bug30596. The problem
was that in cases when groups in GROUP BY correspond to only one row,
and there is ORDER BY, the GROUP BY was removed and the ORDER BY
rewritten to ORDER BY <group_by_columns> without checking if the
columns in GROUP BY and ORDER BY are compatible. This led to
incorrect ordering of the result set as it was sorted using the
GROUP BY columns. Additionaly, the code discarded ASC/DESC modifiers
from ORDER BY even if its columns were compatible with the GROUP BY
ones.
This patch fixes the regression by checking if ORDER BY columns form a
prefix of the GROUP BY ones, and rewriting ORDER BY only in that case,
preserving the ASC/DESC modifiers. That check is sufficient, since the
GROUP BY columns contain a unique index.
mysql-test/r/group_by.result:
Added a test case for bug #32202.
mysql-test/t/group_by.test:
Added a test case for bug #32202.
sql/sql_select.cc:
In cases when groups in GROUP BY correspond to only one row and there
is ORDER BY, rewrite the query to ORDER BY <group_by_columns> only if
the columns in ORDER BY and GROUP BY are compatible, i.e. either one
forms a prefix for another.
tables or more
The problem was that the optimizer used the join buffer in cases when
the result set is ordered by filesort. This resulted in the ORDER BY
clause being ignored, and the records being returned in the order
determined by the order of matching records in the last table in join.
Fixed by relaxing the condition in make_join_readinfo() to take
filesort-ordered result sets into account, not only index-ordered ones.
mysql-test/r/select.result:
Added a test case for bug #30666.
mysql-test/t/select.test:
Added a test case for bug #30666.
sql/sql_select.cc:
Relaxed the condition to determine when the join buffer usage must be
disabled. The condition is now true for cases when the result set is
ordered by filesort, that is when 'join->order &&
!join->skip_sort_order' is true.
The HAVING clause is subject to the same rules as the SELECT list
about using aggregated and non-aggregated columns.
But this was not enforced when processing implicit grouping from
using aggregate functions.
Fixed by performing the same checks for HAVING as for SELECT.
mysql-test/r/func_group.result:
Bug #31794: test case
mysql-test/t/func_group.test:
Bug #31794: test case
sql/sql_select.cc:
Bug #31794: Check HAVING in addition to SELECT list
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
client/mysqldump.c:
Auto merged
include/config-win.h:
Auto merged
libmysql/libmysql.c:
Auto merged
myisam/sort.c:
Auto merged
mysql-test/r/func_sapdb.result:
Auto merged
mysql-test/r/variables.result:
Auto merged
mysql-test/t/variables.test:
Auto merged
sql/field.cc:
Auto merged
sql/ha_innodb.cc:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_sum.cc:
Auto merged
sql/item_timefunc.h:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
tests/mysql_client_test.c:
Auto merged
mysql-test/r/type_datetime.result:
manual merge
mysql-test/r/type_decimal.result:
manual merge
mysql-test/t/type_datetime.test:
manual merge
mysql-test/t/type_decimal.test:
manual merge
sql/item.cc:
manual merge
myisam/mi_write.c:
type conversion fixed
myisam/sort.c:
type conversion fixed
sql/ha_federated.cc:
type conversion fixed
sql/ha_heap.cc:
type conversion fixed
sql/ha_innodb.cc:
type conversion fixed
sql/ha_myisam.cc:
type conversion fixed
sql/opt_range.cc:
type conversion fixed
sql/sql_map.cc:
type conversion fixed
sql/sql_select.cc:
type conversion fixed
sql/sql_update.cc:
type conversion fixed
CPUs / Intel's ICC compile
The bug is a combination of two problems:
1. IA64/ICC MySQL binaries use glibc's qsort(), not the one in mysys.
2. The order relation implemented by join_tab_cmp() is not transitive,
i.e. it is possible to choose such a, b and c that (a < b) && (b < c)
but (c < a). This implies that result of a sort using the relation
implemented by join_tab_cmp() depends on the order in which
elements are compared, i.e. the result is implementation-specific. Since
choose_plan() uses qsort() to pre-sort the
join tables using join_tab_cmp() as a compare function, the results of
the sorting may vary depending on qsort() implementation.
It is neither possible nor important to implement a better ordering
algorithm in join_tab_cmp(). Therefore the only way to fix it is to
force our own qsort() to be used by renaming it to my_qsort(), so we don't depend
on linker to decide that.
This patch also "fixes" bug #20530: qsort redefinition violates the
standard.
include/my_sys.h:
Renamed qsort() and qsort2() to my_qsort() and my_qsort2(). Since
previously we relied on stdlib.h to provide a declaration for qsort(), a
separate declaration for my_qsort() is now required.
libmysql/Makefile.shared:
Added mf_qsort.c to libmysql, since my_lib.c now uses my_qsort() instead of qsort().
myisam/ft_boolean_search.c:
Replaced qsort2() with my_qsort2().
myisam/ft_nlq_search.c:
Replaced qsort2() with my_qsort2().
myisam/myisampack.c:
Replaced qsort() with my_qsort().
myisam/sort.c:
Replaced qsort2() with my_qsort2().
mysys/mf_keycache.c:
Replaced qsort() with my_qsort().
mysys/mf_qsort.c:
Renamed qsort() to my_qsort() and qsort2() to my_qsort2().
mysys/mf_sort.c:
Replaced qsort2() with my_qsort2().
mysys/my_lib.c:
Replaced qsort() with my_qsort().
mysys/queues.c:
Replaced qsort2() with my_qsort2().
sql/item_cmpfunc.cc:
Replaced qsort2() with my_qsort2().
sql/item_cmpfunc.h:
Replaced qsort2() with my_qsort2().
sql/opt_range.cc:
Replaced qsort() with my_qsort().
sql/records.cc:
Replaced qsort() with my_qsort().
sql/sql_acl.cc:
Replaced qsort() with my_qsort().
sql/sql_array.h:
Replaced qsort() with my_qsort().
sql/sql_help.cc:
Replaced qsort() with my_qsort().
sql/sql_select.cc:
Replaced qsort() with my_qsort().
sql/examples/ha_tina.cc:
Replaced qsort() with my_qsort().
sql/sql_table.cc:
Replaced qsort() with my_qsort().
bitmap_is_set(table->write_set, fiel
Problem: creating a temporary table we allocate the group buffer if needed
followed by table bitmaps (see create_tmp_table()). Reserving less memory for
the group buffer than actually needed (used) for values retrieval may lead
to overlapping with followed bitmaps in the memory pool that in turn leads
to unpredictable consequences.
As we use Item->max_length sometimes to calculate group buffer size,
it must be set to proper value. In this particular case
Item_datetime_typecast::max_length is too small.
Another problem is that we use max_length to calculate the group buffer
key length for items represented as DATE/TIME fields which is superfluous.
Fix: set Item_datetime_typecast::max_length properly,
accurately calculate the group buffer key length for items
represented as DATE/TIME fields in the buffer.
mysql-test/r/type_datetime.result:
Fix for bug #31249: Assertion `!table || (!table->write_set ||
bitmap_is_set(table->write_set, fiel
- test result.
mysql-test/t/type_datetime.test:
Fix for bug #31249: Assertion `!table || (!table->write_set ||
bitmap_is_set(table->write_set, fiel
- test case.
sql/item_timefunc.h:
Fix for bug #31249: Assertion `!table || (!table->write_set ||
bitmap_is_set(table->write_set, fiel
- set Item_datetime_typecast::max_length properly.
sql/sql_select.cc:
Fix for bug #31249: Assertion `!table || (!table->write_set ||
bitmap_is_set(table->write_set, fiel
- the group buffer key length for items represented as
DATE/TIME fields in the buffer should be calculated using
the maximum pack length of such fields (== 8), using
max_length here is redundant.
The change_to_use_tmp_fields function leaves the orig_table member of an
expression's tmp table field filled for the new Item_field being created.
Later orig_table is used by the Field::make_field function to provide some
info about original table and field name to a user. This is ok for a field
but for an expression it should be empty.
The change_to_use_tmp_fields function now resets orig_table member of
an expression's tmp table field to prevent providing a wrong info to a user.
The Field::make_field function now resets the table_name and the org_col_name
variables when the orig_table is set to 0.
sql/field.cc:
Bug#27990: Wrong info in MYSQL_FIELD struct members when a tmp table was used.
The Field::make_field function now resets the table_name and the org_col_name
variables when the orig_table is set to 0.
sql/sql_select.cc:
Bug#27990: Wrong info in MYSQL_FIELD struct members when a tmp table was used.
The change_to_use_tmp_fields function now resets orig_table member of
an expression's tmp table field to prevent providing a wrong info to a user.
tests/mysql_client_test.c:
The test case for the bug#21635 is altered to test behavior on both const and
non-const tables.
When storing the VIEW the CREATE VIEW command is reconstructed
from the parse tree. While constructing the command string
the index hints specified should also be printed.
Fixed by adding code to print the index hints when printing a
table in the FROM clause.
mysql-test/r/view.result:
Bug #28702: test case
mysql-test/t/view.test:
Bug #28702: test case
sql/sql_select.cc:
Bug #28702: preserve index hints in a VIEW definition.
sql/table.h:
Bug #28702: preserve index hints in a VIEW definition.
into sita.local:/Users/tsmith/m/bk/maint/50
client/mysql.cc:
Auto merged
client/mysqldump.c:
Auto merged
mysql-test/Makefile.am:
Auto merged
sql/sql_select.cc:
Auto merged
The optimizer sets index traversal in reverse order only if there are
used key parts that are not compared to a constant.
However using the primary key as an ORDER BY suffix rendered the check
incomplete : going in reverse order must still be used even if
all the parts of the secondary key are compared to a constant.
Fixed by relaxing the check and set reverse traversal even when all
the secondary index keyparts are compared to a const.
Also account for the case when all the primary keys are compared to a
constant.
mysql-test/r/innodb_mysql.result:
Bug #31001: test case
mysql-test/t/innodb_mysql.test:
Bug #31001: test case
sql/sql_select.cc:
Bug #31001:
- account for the case when all the primary key parts are compared
to a constant
- force test_if_skip_sort_order to go backwards over the key even
when the number of keyparts used is the same as the number of
keyparts equal to a constant. (because of the primary key
suffix).
into linux-st28.site:/home/martin/mysql/src/bugx/my50-bugx
mysql-test/t/innodb_mysql.test:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/r/innodb_mysql.result:
SCCS merged
Currently the Last_query_cost session status variable shows
only the cost of a single flat subselect. For complex queries
(with subselects or unions etc) Last_query_cost is not valid
as it was showing the cost for the last optimized subselect.
Fixed by reseting to zero Last_query_cost when the complete
cost of the query cannot be determined.
Last_query_cost will be non-zero only for single flat queries.
mysql-test/r/status.result:
Bug #30377: test case
mysql-test/t/status.test:
Bug #30377: test case
sql/sql_lex.h:
Bug #30377: helper function
sql/sql_select.cc:
Bug #30377: don't assign cost if not on single level statement
The optimization that uses a unique index to remove GROUP BY, did not
ensure that the index was actually used, thus violating the ORDER BY
that is impled by GROUP BY.
Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains
a unique index. In case GROUP BY ... ORDER BY null is used, GROUP BY is
simply removed.
BitKeeper/etc/ignore:
Added support-files/mysqld_multi.server tests/bug25714 cscope.in.out cscope.out cscope.po.out to the ignore list
mysql-test/r/distinct.result:
Bug#30596: Changed test case.
Prior to Bug#16458, These queries use temp table and filesort. The
bug was that they used a temp table. However, that patch removed
filesort also, in which case we can no longer gurantee correct ordering.
mysql-test/r/group_by.result:
Bug#30596: Correct result
mysql-test/r/innodb_mysql.result:
Bug#30596: Test case for innodb. Here, as opposed to for MyISAM, row
lookup is done using index whenever the index covers the group list.
mysql-test/t/group_by.test:
Bug#30596: Test case
mysql-test/t/innodb_mysql.test:
Bug#30596: Test case
sql/sql_select.cc:
Bug#30596: The fix, replacing GROUP BY with ORDER BY unless
ORDER BY [NULL|<constant>]
The server created temporary tables for filesort in the working directory
instead of the specified tmpdir directory.
sql/item.cc:
Fixed bug #30287.
The Item_field::set_field method has been modified to reset the any_privileges
flag to false in case of system temporary table. This modification prevents the
server from unnecessary checking of user privileges to access system temporary
tables.
sql/sql_select.cc:
Fixed bug #30287.
Bugfix for #29015 has been removed: TABLE_SHARE::table_name of system
temporary tables contains full path to table file basename again.
sql/sql_view.cc:
Fixed bug #30287.
Commentary has been added.
HEAP tables can't index BIT fields. Due to this when grouping by such fields is
needed they are converted to a fields of the LONG type when temporary table
is being created. But a side effect of this is that a wrong type of BIT
fields is returned to a client.
Now the JOIN::prepare and the create_distinct_group functions are create
additional hidden copy of BIT fields to preserve original fields untouched.
New hidden fields are used for grouping instead.
mysql-test/t/type_bit.test:
Added a test case for the bug#30245: A wrong type of a BIT field is reported when grouped by it.
mysql-test/r/type_bit.result:
Added a test case for the bug#30245: A wrong type of a BIT field is reported when grouped by it.
sql/sql_select.cc:
Bug#30245: A wrong type of a BIT field is reported when grouped by it.
Now the JOIN::prepare and the create_distinct_group functions are create
additional hidden copy of BIT fields to preserve original fields untouched.
New hidden fields are used for grouping instead.
