The reason it happened was that both, JOIN::cleanup() and JOIN::join_free(),
went over all nested joins and called cleanup/join_free for them.
For that:
- split recursive and non-recursive parts of JOIN::cleanup() and
JOIN::join_free()
- rename JOIN::cleanup to JOIN::destroy, as it actually destroys its
argument
- move the recursive part of JOIN::cleanup to st_select_lex::cleanup
- move the non-recursive part of JOIN::join_free to the introduced
method JOIN::cleanup().
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.
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.
We need every instruction to have its own arena, because we want to
track instruction's state (INITIALIZED_FOR_SP -> EXECUTED). Because of
`if' statements and other conditional instructions used in stored
procedures, not every instruction of a stored procedure gets executed
during the first (or even subsequent) execution of the procedure.
So it's better if we track the execution state of every instruction
independently.
All instructions of a given procedure now also share sp_head's
mem_root, but keep their own free_list.
This simplifies juggling with free Item lists in sp_head::execute.
- free_items() moved to be a member of Query_arena.
- logic of 'backup_arena' debug member of Query_arena has been
changed to support
multi-backups. Until now, TRUE 'backup_arena' meant that there is
exactly one active backup of the THD arena. Now it means simply that
the arena is used for backup, so that we can't accidentally overwrite an
existing backup. This allows doing multiple backups, e.g. in
sp_head::execute and Cursor::fetch, when THD arena is already backed up
but we want to set yet another arena (usually the 'permanent' arena,
to save permanent transformations/optimizations of a parsed tree).
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.
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.
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.
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.
