Bug#10568 - Function 'LAST_DAY(date)' does not return NULL for invalid argument.
Manual merge.
include/my_global.h:
Auto merged
mysql-test/t/heap_hash.test:
Auto merged
sql/ha_heap.h:
Auto merged
sql/item_timefunc.cc:
Auto merged
mysql-test/r/func_time.result:
Manual merge.
Used local for the backported fix for Bug#10568.
mysql-test/r/heap_hash.result:
Bug#10178 - failure to find a row in heap table by concurrent UPDATEs
Manual merge.
mysql-test/t/func_time.test:
Manual merge.
Used local for the backported fix for Bug#10568.
sql/ha_heap.cc:
Bug#10178 - failure to find a row in heap table by concurrent UPDATEs
Manual merge.
Wrong comparing method were choosen which results in false comparison.
Make Item_bool_func2::fix_length_and_dec() to get type and field from
real_item() to make REF_ITEM pass the check.
sql/item_cmpfunc.cc:
Fix bug#11325 Wrong date comparison in views
mysql-test/t/view.test:
Test case for bug#11325 Wrong date comparison in views.
mysql-test/r/view.result:
Test case for bug#11325 Wrong date comparison in views.
Moved the key statistics update to info().
The table is not locked in open(). This made wrong stats possible.
No test case for the test suite.
This happens only with heavy concurrency.
A test script is added to the bug report.
mysql-test/r/heap_hash.result:
Bug#10178 - failure to find a row in heap table by concurrent UPDATEs
Updated test results to reflect the new statistics behaviour.
mysql-test/t/heap_hash.test:
Bug#10178 - failure to find a row in heap table by concurrent UPDATEs
Added a FLUSH TABLES to avoid statistics differences between normal
and ps-protocol tests.
sql/ha_heap.cc:
Bug#10178 - failure to find a row in heap table by concurrent UPDATEs
Moved the key statistics update to info().
The table is not locked in open(). This made wrong stats possible.
sql/ha_heap.h:
Bug#10178 - failure to find a row in heap table by concurrent UPDATEs
Added an element to track the validity of the key statistics.
mysql-test/r/view.result:
using encrypt & substring_index in view
mysql-test/t/view.test:
using encrypt & substring_index in view
sql/item_strfunc.h:
fixed encrypt() print
mysql-test/r/query_cache.result:
queries with subquery in the FROM clause
mysql-test/t/query_cache.test:
queries with subquery in the FROM clause
sql/sql_cache.cc:
temporary tables of subquery in the from clause just skipped during processing QC tables
Might need a restart after test with special TZ
Removed unused argument to run_mysqltest()
mysql-test/mysql-test-run.pl:
Might need a restart after test with special TZ
Removed unused argument to run_mysqltest()
#define macro improvement
mysql-test/r/sp-security.result:
BUG#9503: reseting correct parameters of thread after error in SP function
mysql-test/t/sp-security.test:
BUG#9503: reseting correct parameters of thread after error in SP function
sql/item_func.cc:
fixed environment restoring in case of error during SP function execution
sql/protocol.cc:
added debug print
sql/sql_class.h:
fixed #defines to force them to be alvaise in piar, and variable name made more complex for accident repeating in other code
Added a test case for bug #10124.
sql_select.h, item_subselect.cc, sql_select.cc:
Fixed bug #10124.
The copy method of the store_key classes can return
STORE_KEY_OK=0, STORE_KEY_FATAL=1, STORE_KEY_CONV=2 now.
field.cc:
Fixed bug #10124.
When ussuing a warning the store methods return 2 instead of 1 now.
sql/field.cc:
Fixed bug #10124.
When ussuing a warning the store methods return 2 instead of 1 now.
sql/sql_select.cc:
Fixed bug #10124.
The copy method of the store_key classes can return
STORE_KEY_OK=0, STORE_KEY_FATAL=1, STORE_KEY_CONV=2 now.
sql/item_subselect.cc:
Fixed bug #10124.
The copy method of the store_key classes can return
STORE_KEY_OK=0, STORE_KEY_FATAL=1, STORE_KEY_CONV=2 now.
sql/sql_select.h:
Fixed bug #10124.
The copy method of the store_key classes can return
STORE_KEY_OK=0, STORE_KEY_FATAL=1, STORE_KEY_CONV=2 now.
mysql-test/t/func_str.test:
Added a test case for bug #10124.
mysql-test/r/func_str.result:
Added a test case for bug #10124.
The source of the problem is in Field_longlong::cmp. If 'this' is
an unsigned number, the method casts both the current value, and
the constant that we compare with to an unsigned number. As a
result if the constant we compare with is a negative number, it
wraps to some unsigned number, and the comparison is incorrect.
When the optimizer chooses the "range" access method, this problem
causes handler::read_range_next to reject the current key when the
upper bound key is a negative number because handler::compare_key
incorrectly considers the positive and negative keys to be equal.
The current patch does not correct the source of the problem in
Field_longlong::cmp because it is not easy to propagate sign
information about the constant at query execution time. Instead
the patch changes the range optimizer so that it never compares
unsiged fields with negative constants. As an added benefit,
queries that do such comparisons will execute faster because
the range optimizer replaces conditions like:
(a) (unsigned_int [< | <=] negative_constant) == FALSE
(b) (unsigned_int [> | >=] negative_constant) == TRUE
with the corresponding constants.
In some cases this may even result in constant time execution.
mysql-test/r/range.result:
- Added test for BUG#11185
- Added missing test from 4.1. This test also tests the fix for BUG#11185.
mysql-test/t/range.test:
- Added test for BUG#11185
- Added missing test from 4.1. This test also tests the fix for BUG#11185.
sql/opt_range.cc:
Added a new optimization to the range optimizer where we detect that
an UNSIGNED field is compared with a negative constant. Depending on
the comparison operator, we know directly that the result of the
comparison is either TRUE or FALSE for all input values, and we need
not check each value.
This optimization is also necessary so that the index range access
method produces correct results when comparing unsigned fields with
negative constants.
Fixed buf #11487.
Added a call of QUICK_RANGE_SELECT::init to the
QUICK_RANGE_SELECT::reset method. Without it the second
evaluation of a subquery employing the range access failed.
subselect.result, subselect.test:
Added a test case for bug #11487.
mysql-test/t/subselect.test:
Added a test case for bug #11487.
mysql-test/r/subselect.result:
Added a test case for bug #11487.
sql/opt_range.cc:
Fixed buf #11487.
Added a call of QUICK_RANGE_SELECT::init to the
QUICK_RANGE_SELECT::reset method. Without it the second
evaluation of a subquery employing the range access failed.
The source of the problem is in Field_longlong::cmp. If 'this' is
an unsigned number, the method casts both the current value, and
the constant that we compare with to an unsigned number. As a
result if the constant we compare with is a negative number, it
wraps to some unsigned number, and the comparison is incorrect.
When the optimizer chooses the "range" access method, this problem
causes handler::read_range_next to reject the current key when the
upper bound key is a negative number because handler::compare_key
incorrectly considers the positive and negative keys to be equal.
The current patch does not correct the source of the problem in
Field_longlong::cmp because it is not easy to propagate sign
information about the constant at query execution time. Instead
the patch changes the range optimizer so that it never compares
unsiged fields with negative constants. As an added benefit,
queries that do such comparisons will execute faster because
the range optimizer replaces conditions like:
(a) (unsigned_int [< | <=] negative_constant) == FALSE
(b) (unsigned_int [> | >=] negative_constant) == TRUE
with the corresponding constants.
In some cases this may even result in constant time execution.
mysql-test/r/range.result:
- Changed incorrect result of an old test
- Added new results for BUG#11185
mysql-test/t/range.test:
- Added new tests for BUG#11185
- Deleted an old comment because now the problem is fixed
sql/opt_range.cc:
Added a new optimization to the range optimizer where we detect that
an UNSIGNED field is compared with a negative constant. Depending on
the comparison operator, we know directly that the result of the
comparison is either TRUE or FALSE for all input values, and we need
not check each value.
This optimization is also necessary so that the index range access
method produces correct results when comparing unsigned fields with
negative constants.
mysql-test/r/func_math.result:
Add new results
mysql-test/t/func_math.test:
Add new regression test
sql/item_func.cc:
Don't set result of abs() to unsigned. Result should still be
a signed value, even if always positive.
mysql-test/r/key.result:
Add new results
mysql-test/t/key.test:
Add new regression test
sql/table.cc:
Use keyinfo->key_parts to determine if key is part of a
multiple-field key or is unique.
