ONLY_FULL_GROUP_BY
Problem was that during checking and preparation of the
partitioining function as a side effect in fix_fields
the full_group_by_flag was changed.
Solution was to set it back to its original value after
calling fix_fields.
Updated patch, to also exclude allow_sum_func from being
affected of fix_fields, as requested by reviewer.
mysql-test/r/partition.result:
Bug#46923: select count(*) from partitioned table fails with
ONLY_FULL_GROUP_BY
Updated result file
mysql-test/t/partition.test:
Bug#46923: select count(*) from partitioned table fails with
ONLY_FULL_GROUP_BY
Extended test case to cover this bug
sql/sql_partition.cc:
Bug#46923: select count(*) from partitioned table fails with
ONLY_FULL_GROUP_BY
Resetting full_group_by_flag and allow_sum_func
back to their original values,
not conflicting with the sql_mode 'ONLY_FULL_GROUP_BY'
additional backport of of bug43138 fix
mysql-test/t/myisam-system.test:
additional backport of of bug43138 fix
sql/sql_db.cc:
additional backport of of bug43138 fix
1. Fixes BUG#44030 - Error: (1500) Couldn't read the MAX(ID) autoinc value
from the index (PRIMARY)
2. Disables the innodb-autoinc test for innodb plugin temporarily.
The testcase for this bug has different result file for InnoDB plugin.
Should add the testcase to Innodb suite with a different result file.
Detailed revision comments:
r5243 | sunny | 2009-06-04 03:17:14 +0300 (Thu, 04 Jun 2009) | 14 lines
branches/5.1: When the InnoDB and MySQL data dictionaries go out of sync, before
the bug fix we would assert on missing autoinc columns. With this fix we allow
MySQL to open the table but set the next autoinc value for the column to the
MAX value. This effectively disables the next value generation. INSERTs will
fail with a generic AUTOINC failure. However, the user should be able to
read/dump the table, set the column values explicitly, use ALTER TABLE to
set the next autoinc value and/or sync the two data dictionaries to resume
normal operations.
Fix Bug#44030 Error: (1500) Couldn't read the MAX(ID) autoinc value from the
index (PRIMARY)
rb://118
r5252 | sunny | 2009-06-04 10:16:24 +0300 (Thu, 04 Jun 2009) | 2 lines
branches/5.1: The version of the result file checked in was broken in r5243.
r5259 | vasil | 2009-06-05 10:29:16 +0300 (Fri, 05 Jun 2009) | 7 lines
branches/5.1:
Remove the word "Error" from the printout because the mysqltest suite
interprets it as an error and thus the innodb-autoinc test fails.
Approved by: Sunny (via IM)
r5466 | vasil | 2009-07-02 10:46:45 +0300 (Thu, 02 Jul 2009) | 6 lines
branches/5.1:
Adjust the failing innodb-autoinc test to conform to the latest behavior
of the MySQL code. The idea and the comment in innodb-autoinc.test come
from Sunny.
The problem is that argument buffer can be used as result buffer
and it leads to argument value change.
The fix is to use 'old buffer' as result buffer only
if first argument is not constant item.
mysql-test/r/func_str.result:
test result
mysql-test/t/func_str.test:
test case
sql/item_strfunc.cc:
The problem is that argument buffer can be used as result buffer
and it leads to argument value change.
The fix is to use 'old buffer' as result buffer only
if first argument is not constant item.
partial backport of bug43138 fix
mysql-test/r/warnings.result:
test result
mysql-test/t/warnings.test:
test case
sql/sql_class.cc:
partial backport of bug43138 fix
sql/sql_class.h:
partial backport of bug43138 fix
sql/sql_table.cc:
partial backport of bug43138 fix
Archive engine returns wrong values for average record length
and max data length.
With this fix they're calculated as following:
- max data length is 2 ^ 63 where large files are supported
and INT_MAX32 where this is not supported;
- average record length is data length / records in data file.
mysql-test/r/archive.result:
A test case for BUG#29203.
mysql-test/t/archive.test:
A test case for BUG#29203.
storage/archive/ha_archive.cc:
Better estimation for average row length and maximal data
file length.
Create temporary InnoDB table fails on case insensitive
filesystems, when lower_case_table_names is 2 (e.g. OS X)
and temporary directory path contains upper case letters.
The problem was that tmpdir prefix was converted to lower
case when table was created, but was passed as is when
table was opened.
Fixed by leaving tmpdir prefix part intact.
mysql-test/r/lowercase_mixed_tmpdir_innodb.result:
A test case for BUG#45638.
mysql-test/t/lowercase_mixed_tmpdir_innodb-master.opt:
A test case for BUG#45638.
mysql-test/t/lowercase_mixed_tmpdir_innodb-master.sh:
A test case for BUG#45638.
mysql-test/t/lowercase_mixed_tmpdir_innodb.test:
A test case for BUG#45638.
sql/handler.cc:
Fixed get_canonical_filename() to not lowercase filesystem
path prefix for temporary tables.
The parser rule for expressions in a udf parameter list contains
two hacks:
First, the parser input stream is read verbatim, bypassing
the lexer.
Second, the Item::name field is overwritten. If the argument to a
udf was a field, the field's name as seen by name resolution was
overwritten this way.
If the field name was quoted or escaped, it would appear as e.g. "`field`".
Fixed by not overwriting field names.
mysql-test/r/udf.result:
Bug#46259: Test result.
mysql-test/t/udf.test:
Bug#46259: Test case.
sql/sql_yacc.yy:
Bug#46259: Fix.
This test case uses mysqlbinlog to dump the content of master-bin.000001,
but the content of master-bin.000001 is not that this test needs.
MTR runs a lot of test cases on one server, so when this test starts, the current binlog file
might not be master-bin.000001, or there are other events are written by tests before.
'RESET MASTER' command must be called at the begin, it ensures that binlog of this test
is wrote to master-bin.000001 correctly.
Three other tests have the same problem, They were fixed together.
mysqlbinlog-cp932
binlog_incident
binlog_tmp_table
The external 'for' loop in remove_dup_with_compare() handled
HA_ERR_RECORD_DELETED by just starting over without advancing
to the next record which caused an infinite loop.
This condition could be triggered on certain data by a SELECT
query containing DISTINCT, GROUP BY and HAVING clauses.
Fixed remove_dup_with_compare() so that we always advance to
the next record when receiving HA_ERR_RECORD_DELETED from
rnd_next().
mysql-test/r/distinct.result:
Added a test case for bug #46159.
mysql-test/t/distinct.test:
Added a test case for bug #46159.
sql/sql_select.cc:
Fixed remove_dup_with_compare() so that we always advance to
the next record when receiving HA_ERR_RECORD_DELETED from
rnd_next().
The plugin feature is disabled, you need HAVE_DLOPEN
Selectively skip tests that require dynamic loading (ie: static builds).
mysql-test/include/have_dynamic_loading.inc:
Add require file.
mysql-test/t/ps_not_windows.test:
Test requires dynamic loading support.
on subquery inside a SP
Problem: repeated call of a SP containing an incorrect query with a
subselect may lead to failed ASSERT().
Fix: set proper sublelect's state in case of error occured during
subquery transformation.
mysql-test/r/sp.result:
Fix for bug#46629: Item_in_subselect::val_int(): Assertion `0'
on subquery inside a SP
- test result.
mysql-test/t/sp.test:
Fix for bug#46629: Item_in_subselect::val_int(): Assertion `0'
on subquery inside a SP
- test case.
sql/item_subselect.cc:
Fix for bug#46629: Item_in_subselect::val_int(): Assertion `0'
on subquery inside a SP
- don't set Item_subselect::changed in the Item_subselect::fix_fields()
if an error occured during subquery transformation.
That prevents us of further processing incorrect subqueries after
Item_in_subselect::select_in_like_transformer().
SELECT with join (not only self-join) from archive table may
return incomplete result set, when result set size exceeds
join buffer size.
The problem was that archive row counter was initialzed too
early, when ha_archive::info() method was called. Later,
when optimizer exceeds join buffer, it attempts to reuse
handler without calling ha_archive::info() again (which is
correct).
Fixed by moving row counter initialization from
ha_archive::info() to ha_archive::rnd_init().
mysql-test/r/archive.result:
A test case for BUG#46961.
mysql-test/t/archive.test:
A test case for BUG#46961.
storage/archive/ha_archive.cc:
Since a cursor may get reused without a call to ::info(),
move assignment of scan_rows to a proper place, that is
::rnd_init().
Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up.
The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy.
mysql-test/r/explain.result:
test result
mysql-test/t/explain.test:
test case
sql/sql_select.cc:
Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up.
The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy.
name as existing view
When trying to create a table with the same name as existing view with
join, mysql server crashes.
The problem is when create table is issued with the same name as view, while
verifying with the existing tables, we assume that base table object is
created always.
In this case, since it is a view over multiple tables, we don't have the
mysql derived table object.
Fixed the logic which checks if there is an existing table to not to assume
that table object is created when the base table is view over multiple
tables.
mysql-test/r/create.result:
BUG#46384 - mysqld segfault when trying to create table with same
name as existing view
Testcase for the bug
mysql-test/t/create.test:
BUG#46384 - mysqld segfault when trying to create table with same
name as existing view
Testcase for the bug
sql/sql_insert.cc:
BUG#46384 - mysqld segfault when trying to create table with same
name as existing view
Fixed create_table_from_items() method to properly check, if the base table
is a view over multiple tables.
function,file sql_base.cc
When uncacheable queries are written to a temp table the optimizer must
preserve the original JOIN structure, because it is re-using the JOIN
structure to read from the resulting temporary table.
This was done only for uncacheable sub-queries.
But top level queries can also benefit from this mechanism, specially if
they're using index access and need a reset.
Fixed by not limiting the saving of JOIN structure to subqueries
exclusively.
Added a new test file to extend the existing (large) subquery.test.
extraneous file
Online/fast ALTER TABLE of a partitioned table may leave
temporary file in database directory.
Fixed by removing unnecessary call to
handler::ha_create_handler_files(), which was creating
partitioning definition file.
mysql-test/r/partition_innodb.result:
A test case for BUG#46483.
mysql-test/t/partition_innodb.test:
A test case for BUG#46483.
sql/unireg.cc:
Do not call ha_create_handler_files() when we were requested
to create only dot-frm file.
results in server crash
check_group_min_max_predicates() assumed the input condition
item to be one of COND_ITEM, SUBSELECT_ITEM, or FUNC_ITEM.
Since a condition of the form "field" is also a valid condition
equivalent to "field <> 0", using such a condition in a query
where the loose index scan was chosen resulted in a debug
assertion failure.
Fixed by handling conditions of the FIELD_ITEM type in
check_group_min_max_predicates().
mysql-test/r/group_min_max.result:
Added a test case for bug #46607.
mysql-test/t/group_min_max.test:
Added a test case for bug #46607.
sql/opt_range.cc:
Handle conditions of the FUNC_ITEM type in
check_group_mix_max_predicates().
mysql-test/r/lock_multi_bug38499.result:
Update test case result.
mysql-test/r/lock_multi_bug38691.result:
Update test case result.
mysql-test/t/lock_multi_bug38499.test:
Do not sync .frm files.
mysql-test/t/lock_multi_bug38691.test:
Do not sync .frm files.
sql/opt_range.cc:
Removed duplicate code (if statement must have been duplicated during earlier merge).
sql/sql_partition.cc:
After mergeing bug#46362 and bug#20577, the NULL partition was also searched
when col = const, fixed by checking if = or range.
field references
This error requires a combination of factors :
1. An "impossible where" in the outermost SELECT
2. An aggregate in the outermost SELECT
3. A correlated subquery with a WHERE clause that includes an outer
field reference as a top level WHERE sargable predicate
When JOIN::optimize detects an "impossible WHERE" it will bail out
without doing the rest of the work and initializations. It will not
call make_join_statistics() as well. And make_join_statistics fills
in various structures for each table referenced.
When processing the result of the "impossible WHERE" the query must
send a single row of data if there are aggregate functions in it.
In this case the server marks all the aggregates as having received
no rows and calls the relevant Item::val_xxx() method on the SELECT
list. However if this SELECT list happens to contain a correlated
subquery this subquery is evaluated in a normal evaluation mode.
And if this correlated subquery has a reference to a field from the
outermost "impossible where" SELECT the add_key_fields will mistakenly
consider the outer field reference as a "local" field reference when
looking for sargable predicates.
But since the SELECT where the outer field reference refers to is not
completely initialized due to the "impossible WHERE" in this level
we'll get a NULL pointer reference.
Fixed by making a better condition for discovering if a field is "local"
to the SELECT level being processed.
It's not enough to look for OUTER_REF_TABLE_BIT in this case since
for outer references to constant tables the Item_field::used_tables()
will return 0 regardless of whether the field reference is from the
local SELECT or not.
When a connection is dropped any remaining temporary table is also automatically
dropped and the SQL statement of this operation is written to the binary log in
order to drop such tables on the slave and keep the slave in sync. Specifically,
the current code base creates the following type of statement:
DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `db`.`table`;
Unfortunately, appending the database to the table name in this manner circumvents
the replicate-rewrite-db option (and any options that check the current database).
To solve the issue, we started writing the statement to the binary as follows:
use `db`; DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `table`;
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.
mysql-test/r/analyse.result:
test result
mysql-test/r/subselect.result:
result fix
mysql-test/t/analyse.test:
test case
mysql-test/t/subselect.test:
test fix
sql/sql_yacc.yy:
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.
Problem was that the partition containing NULL values
was pruned away, since '2001-01-01' < '2001-02-00' but
TO_DAYS('2001-02-00') is NULL.
Added the NULL partition for RANGE/LIST partitioning on TO_DAYS()
function to be scanned too.
Also fixed a bug that added ALLOW_INVALID_DATES to sql_mode
(SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST
partitioned table would add it).
mysql-test/include/partition_date_range.inc:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Added include file to decrease test code duplication
mysql-test/r/partition_pruning.result:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Added test results
mysql-test/r/partition_range.result:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Updated test result.
This fix adds the partition containing NULL values to
the list of partitions to be scanned.
mysql-test/t/partition_pruning.test:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Added test case
sql/item.h:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Added MONOTONIC_*INCREASE_NOT_NULL values to be used by TO_DAYS.
sql/item_timefunc.cc:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Calculate the number of days as return value even for invalid dates.
This is so that pruning can be used even for invalid dates.
sql/opt_range.cc:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Fixed a bug that added ALLOW_INVALID_DATES to sql_mode
(SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST
partitioned table would add it).
sql/partition_info.h:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Resetting ret_null_part when a single partition is to be used, this
to avoid adding the NULL partition.
sql/sql_partition.cc:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Always include the NULL partition if RANGE or LIST.
Use the returned value for the function for pruning, even if
it is marked as NULL, so that even '2000-00-00' can be
used for pruning, even if TO_DAYS('2000-00-00') is NULL.
Changed == to >= in get_next_partition_id_list to avoid
crash if part_iter->part_nums is not correctly setup.
There were a problem since pruning uses the field
for comparison (while evaluate_join_record uses longlong),
resulting in pruning failures when comparing DATE to DATETIME.
Fix was to always comparing DATE vs DATETIME as DATETIME,
by adding ' 00:00:00' to the DATE string.
And adding optimization for comparing with 23:59:59, so that
DATETIME_col > '2001-02-03 23:59:59' ->
TO_DAYS(DATETIME_col) > TO_DAYS('2001-02-03 23:59:59') instead
of '>='.
mysql-test/r/partition_pruning.result:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Updated result-file
mysql-test/t/partition_pruning.test:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Added testcases.
sql-common/my_time.c:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
removed duplicate assignment.
sql/item.cc:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Changed field_is_equal_to_item into field_cmp_to_item, to
better handling DATE vs DATETIME comparision.
sql/item.h:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Updated comment
sql/item_timefunc.cc:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Added optimization (pruning) of DATETIME where time-part is
23:59:59
sql/opt_range.cc:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Using the new stored_field_cmp_to_item for better pruning.
The problem was that creating a DECIMAL column from a decimal
value could lead to a failed assertion as decimal values can
have a higher precision than those attached to a table. The
assert could be triggered by creating a table from a decimal
with a large (> 30) scale. Also, there was a problem in
calculating the number of digits in the integral and fractional
parts if both exceeded the maximum number of digits permitted
by the new decimal type.
The solution is to ensure that truncation procedure is executed
when deducing a DECIMAL column from a decimal value of higher
precision. If the integer part is equal to or bigger than the
maximum precision for the DECIMAL type (65), the integer part
is truncated to fit and the fractional becomes zero. Otherwise,
the fractional part is truncated to fit into the space left
after the integer part is copied.
This patch borrows code and ideas from Martin Hansson's patch.
mysql-test/r/type_newdecimal.result:
Add test case result for Bug#45261. Also, update test case to
reflect that an additive operation increases the precision of
the resulting type by 1.
mysql-test/t/type_newdecimal.test:
Add test case for Bug#45261
sql/field.cc:
Added DBUG_ASSERT to ensure object's invariant is maintained.
Implement method to create a field to hold a decimal value
from an item.
sql/field.h:
Explain member variable. Add method to create a new decimal field.
sql/item.cc:
The precision should only be capped when storing the value
on a table. Also, this makes it impossible to calculate the
integer part if Item::decimals (the scale) is larger than the
precision.
sql/item.h:
Simplify calculation of integer part.
sql/item_cmpfunc.cc:
Do not limit the precision. It will be capped later.
sql/item_func.cc:
Use new method for allocating a new decimal field.
Add a specialized method for retrieving the precision
of a user variable item.
sql/item_func.h:
Add method to return the precision of a user variable.
sql/item_sum.cc:
Use new method for allocating a new decimal field.
sql/my_decimal.h:
The integer part could be improperly calculated for a decimal
with 31 digits in the fractional part.
sql/sql_select.cc:
Use new method which truncates the integer or decimal parts
as needed.
INSERT ... SELECT ...
Problem was that when bulk insert is used on an empty
table/partition, it disables the indexes for better
performance, but in this specific case it also tries
to read from that partition using an index, which is
not possible since it has been disabled.
Solution was to allow index reads on disabled indexes
if there are no records.
Also reverted the patch for bug#38005, since that was a workaround
in the partitioning engine instead of a fix in myisam.
mysql-test/r/partition.result:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
updated result file
mysql-test/t/partition.test:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
Added testcase
sql/ha_partition.cc:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
reverted the patch for bug#38005, since that was a workaround
around this problem, not needed after fixing it in myisam.
storage/myisam/mi_search.c:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
Return HA_ERR_END_OF_FILE instead of HA_ERR_WRONG_INDEX
when there are no rows.
