- QUICK_INDEX_MERGE_SELECT deinitializes its rnd_pos() scan when it reaches EOF, but we
need to make the deinitialization in QUICK_INDEX_MERGE_SELECT destructor also. This is because
certain execution strategies can stop scanning without reaching EOF, then then try to do a full
table scan on this table. Failure to deinitialize caused the full scan to use (already empty)
table->sort and produce zero records.
Field_varstring::store
The code that temporary saved the bitmaps of the read set and the write set so that
it can set it to all columns for debug purposes was not expecting that the
table->read_set and table->write_set can be the same. And was always saving both in
sequence.
As a result the original value was never restored.
Fixed by saving & restoring the original value only once if the two sets are the
same (in a special set of functions).
Select with a "NULL NOT IN" condition containing complex
subselect from the same table as in the outer select failed
with an assertion.
The failure was caused by a concatenation of circumstances:
1) an inner select was optimized by make_join_statistics to use
the QUICK_RANGE_SELECT access method (that implies an index
scan of the table);
2) a subselect was independent (constant) from the outer select;
3) a condition was pushed down into inner select.
During the evaluation of a constant IN expression an optimizer
temporary changed the access method from index scan to table
scan, but an engine handler was already initialized for index
access by make_join_statistics. That caused an assertion.
Unnecessary index initialization has been removed from
the QUICK_RANGE_SELECT::init method (QUICK_RANGE_SELECT::reset
reinvokes this initialization).
crashes server
When creating temporary table that contains aggregate functions a
non-reversible source transformation was performed to redirect aggregate
function arguments towards temporary table columns.
This caused EXPLAIN EXTENDED to fail because it was trying to resolve
references to the (freed) temporary table.
Fixed by preserving the original aggregate function arguments and
using them (instead of the transformed ones) for EXPLAIN EXTENDED.
problems are located in the sql_partition.cc where functions calculation
partition_id don't expect error returned from item->val_int().
Fixed by adding checks to these functions.
Note - it tries to fix more problems than just the reported bug.
per-file comments:
modified:
mysql-test/r/partition.result
Bug#38083 Error-causing row inserted into partitioned table despite error
test result
mysql-test/t/partition.test
Bug#38083 Error-causing row inserted into partitioned table despite error
test case
sql/opt_range.cc
Bug#38083 Error-causing row inserted into partitioned table despite error
get_part_id() call fixed
sql/partition_info.h
Bug#38083 Error-causing row inserted into partitioned table despite error
get_subpart_id_func interface changed.
sql/sql_partition.cc
Bug#38083 Error-causing row inserted into partitioned table despite error
various functions calculationg partition_id and subpart_id didn't expect
an error returned from item->val_int(). Error checks added.
When analyzing the possible index use cases the server was re-using an internal structure.
This is wrong, as this internal structure gets updated during the analysis.
Fixed by making a copy of the internal structure for every place it needs to be used.
Also stopped the generation of empty SEL_TREE structures that unnecessary
complicate the analysis.
Range scan in descending order for c <= <col> <= c type of
ranges was ignoring the DESC flag.
However some engines like InnoDB have the primary key parts
as a suffix for every secondary key.
When such primary key suffix is used for ordering ignoring
the DESC is not valid.
But we generally would like to do this because it's faster.
Fixed by performing only reverse scan if the primary key is used.
Removed some dead code in the process.
Range scan in descending order for c <= <col> <= c type of
ranges was ignoring the DESC flag.
However some engines like InnoDB have the primary key parts
as a suffix for every secondary key.
When such primary key suffix is used for ordering ignoring
the DESC is not valid.
But we generally would like to do this because it's faster.
Fixed by performing only reverse scan if the primary key is used.
Removed some dead code in the process.
- In QUICK_INDEX_MERGE_SELECT::read_keys_and_merge: when we got table->sort from Unique,
tell init_read_record() not to use rr_from_cache() because a) rowids are already sorted
and b) it might be that the the data is used by filesort(), which will need record rowids
(which rr_from_cache() cannot provide).
- Fully de-initialize the table->sort read in QUICK_INDEX_MERGE_SELECT::get_next(). This fixes BUG#35477.
(bk trigger: file as fix for BUG#35478).
WHERE f1 < n ignored row if f1 was indexed integer column and
f1 = TYPE_MAX ^ n = TYPE_MAX+1. The latter value when treated
as TYPE overflowed (obviously). This was not handled, it is now.
cause ROLLBACK of statement", part 1. Review fixes.
Do not send OK/EOF packets to the client until we reached the end of
the current statement.
This is a consolidation, to keep the functionality that is shared by all
SQL statements in one place in the server.
Currently this functionality includes:
- close_thread_tables()
- log_slow_statement().
After this patch and the subsequent patch for Bug#12713, it shall also include:
- ha_autocommit_or_rollback()
- net_end_statement()
- query_cache_end_of_result().
In future it may also include:
- mysql_reset_thd_for_next_command().
memory corruptions.
The right pointer field of the SEL_ARG structure was not
initialized in the constructor and sometimes that led to
server crashes.
There is no testcase because the bug occurs only when
uninitialized memory has particular values, which can't be
re-created in the test suite.
This bug is actually two. The first one manifests itself on an EXPLAIN
SELECT query with nested subqueries that employs the filesort algorithm.
The whole SELECT under explain is marked as UNCACHEABLE_EXPLAIN to preserve
some temporary structures for explain. As a side-effect of this values of
nested subqueries weren't cached and subqueries were re-evaluated many
times. Each time buffer for filesort was allocated but wasn't freed because
freeing occurs at the end of topmost SELECT. Thus all available memory was
eaten up step by step and OOM event occur.
The second bug manifests itself on SELECT queries with conditions where
a subquery result is compared with a key field and the subquery itself also
has such condition. When a long chain of such nested subqueries is present
the stack overrun occur. This happens because at some point the range optimizer
temporary puts the PARAM structure on the stack. Its size if about 8K and
the stack is exhausted very fast.
Now the subselect_single_select_engine::exec function allows subquery result
caching when the UNCACHEABLE_EXPLAIN flag is set.
Now the SQL_SELECT::test_quick_select function calls the check_stack_overrun
function for stack checking purposes to prevent server crash.
