A crash may happenin the cases when the range optimizer tried to OR
two index merge such that the second one contained less range trees
than the first one.
The bug was introduced by the patch of MWL#24:
"index_merge: fair choice between index_merge union and range access".
If a primary key was used in the index intersection for
an InnoDB database the size of the memory allocated
for the best index intersection plan was one element less
than it was needed. That could cause a memory overwrite
and a crash as a result of it.
A crash may happenin the cases when the range optimizer tried to OR
two index merge such that the second one contained less range trees
than the first one.
The bug was introduced by the patch of MWL#24:
"index_merge: fair choice between index_merge union and range access".
independent execution plans.
Fixed a bug in Unique::unique_add that caused a crash for a query from
index_intersect_innodb on some platforms.
Fixed two bugs in opt_range.cc that led to the choice of not the
cheapest plans for index intersections.
Fix MySQL BUG#52344 - Subquery materialization: Assertion if subquery in on-clause of outer join
Original fix and comments from Oysten, adjusted for the different
subquery optimization in MariaDB.
"
Problem: If tables of an outer join are constant tables,
the associated on-clause will be evaluated in the optimization
phase. If the on-clause contains a query that is to be
executed with subquery materialization, this will not work
since the infrastructure for such execution is not yet set up.
Solution: Do not evaluate on-clause in optimization phase if
is_expensive() returns true for this clause. This is how the
problem is currently avoided for where-clauses. This works
because, Item_in_subselect::is_expensive_processor returns true
if query is to be executed with subquery materialization.
"
In addition, after MWL#89, in MariaDB if the IN-EXISTS strategy
is chosen, the in-to-exists predicates are insterted after
join_read_const_table() is called, resulting in evaluation of
the subquery without the in-to-exists predicates.
Open issues:
- A better fix for #57688; Igor is working on this
- Test failure in index_merge_innodb.test ; Igor promised to look at this
- Some Innodb tests fails (need to merge with latest xtradb) ; Kristian promised to look at this.
- Failing tests: innodb_plugin.innodb_bug56143 innodb_plugin.innodb_bug56632 innodb_plugin.innodb_bug56680 innodb_plugin.innodb_bug57255
- Werror is disabled; Should be enabled after merge with xtradb.
Analysis:
The send_data method of the result sink class used to collect
data statistics about materialized subqueries incorrectly assumed
that duplicate rows are removed prior to calling send_data. As
a result the collected statistics was wrong, which resulted in
an incorrect maximal number of keys in the Ordered_key buffer.
Solution:
Try to insert each row into the materialized temp table before
collecting statistics, and if the insertion results in a duplicate
row, do not count the current row.
Registration of pointer change if we assign it to other pointer which should be identical after statement execution (PS/SP).
mysql-test/r/subselect.result:
Test suite.
mysql-test/t/subselect.test:
Test suite.
sql/sql_class.cc:
The procedure of the pointer registration.
sql/sql_class.h:
The procedure of the pointer registration.
sql/sql_lex.cc:
Registration of pointer change if we assign it to other pointer which should be identical after statement execution (PS/SP).
mysql-test/r/heap_btree.result:
Test of index over bit firld in hash table.
mysql-test/r/heap_hash.result:
Test of index over bit firld in hash table.
mysql-test/t/heap_btree.test:
Test of index over bit firld in hash table.
mysql-test/t/heap_hash.test:
Test of index over bit firld in hash table.
storage/heap/ha_heap.cc:
Adding bit field support for heap tables.
storage/heap/hp_create.c:
Adding bit field support for heap tables.
storage/heap/hp_hash.c:
Adding bit field support for heap tables.
The bug happened when BKA join algorithm used an incremental buffer
and some of the fields over which access keys were constructed
- were allocated in the previous join buffers
- were non-nullable
- belonged to inner tables of outer joins.
For such fields an offset to the field value in the record is saved
in the postfix of the record, and a zero offset indicates that the value
is null. Before the key using the field value is constructed the
value is read into the corresponding field of the record buffer and
the null bit is set for the field if the offset is 0. However if
the field is non-nullable the table->null_row must be set to 1
for null values and to 0 for non-null values to ensure proper reading
of the value from the record buffer.
The condition that was supposed to check whether a join table
is an inner table of a nested outer join or semi-join was not
quite correct in the code of the function check_join_cache_usage.
That's why some queries with nested outer joins triggered
an assertion failure.
Encapsulated this condition in the new method called
JOIN_TAB::is_nested_inner and provided a proper code for it.
Also corrected a bug in the code of check_join_cache_usage()
that caused a downgrade of not first join buffers of the
level 5 and 7 to level 4 and 6 correspondingly.
When pushing the condition for a table in the function
JOIN_TAB::make_scan_filter the optimizer must not push
conditions from WHERE if the table is some inner table
of an outer join..
The condition over outer tables extracted from the on expression
for a outer join must be ANDed to the condition pushed to the
first inner table of this outer join only.
Nested outer joins cannot use flat join buffers. So if join_cache_level
is set to 1 then any join algorithm employing join buffers cannot be used
for nested outer joins.
The patch that introduced the new enumeration type Match_flag
for the values of match flags in the records put into join buffers
missed the necessary modifications in JOIN_CACHE::set_match_flag_if_none.
This could cause wrong results for outer joins with on expressions
only over outer tables.
A non-incremental join buffer cannot be used for inner tables of nested
outer joins. That's why when join_cache_level is set to 7 it must
be downgraded to level 6 for the inner tables of nested outer joins.
For the same reason with join_cache_level set to 3 no join buffer is
used for the inner tables of outer joins (we could downgrade it to
level 2, but this level does not support ref access).
Miscalculation of the minimum possible buffer size could trigger
an assert in JOIN_CACHE_HASHED::put_record when if join_buffer_size
was set to the values that is less than the length of one record to
stored in the join buffer.
It happened due to the following mistakes:
- underestimation of space needed for a key in the hash table
(we have to take into account that hash table can have more
buckets than the expected number of records).
- the value of maximum total length of all records stored in
the join buffer was not saved in the field max_used_fieldlength
by the function calc_used_field_length.
Currently BNLH join uses a simplified implementation of hash function
when hash function is calculated over the whole key buffer, not only
the significant bytes of it. It means that both building keys and
probing keys both must fill insignificant bytes with the same filler.
Usually 0 is used as such a filler.
Yet the code before patch filled insignificant bytes only for probing
keys.
When probing into the hash table of a hashed join cache is performed
the key value should not constructed in the buffer used to build keys
in the hash tables. The constant parts of these keys copied only once,
so they should not be ever overwritten. Otherwise wrong results
can be produced by queries that employ hashed join buffers.
Implement os_event_wait_time() for POSIX systems.
In the purge thread, use os_event_wait_time() when sleeping rather than sleep,
and signal the event when server shuts down, so we do not need to wait for
upto 10 seconds until the purge thread wakes up.
Also fix bug that warnings that were pushed after we call set_ok_status() were
not included in the waning count sent to the client in the result packet.
Also in mysqltest, in recursive die() invocation at least print the message
before aborting.
client/mysqltest.cc:
If we detect recursive die(), at least print the message before aborting.
mysql-test/r/warnings_debug.result:
Test case.
mysql-test/t/warnings_debug.test:
Test case.
sql/handler.cc:
Force generation of a warning with specific debug option, for testing.
sql/protocol.cc:
Fix wrong DBUG_ENTER
sql/sql_class.h:
Add method to count warnings pushed after set_ok_status() is called.
sql/sql_error.cc:
Also count warnings pushed after set_ok_status() is called.
storage/xtradb/include/os0sync.h:
Implement working os_sync_wait_time() for POSIX.
storage/xtradb/include/srv0srv.h:
Make the purge thread wait for an event when sleeping, so we can signal it to
wakeup immediately at shutdown.
storage/xtradb/log/log0log.c:
Make the purge thread wait for an event when sleeping, so we can signal it to
wakeup immediately at shutdown.
storage/xtradb/os/os0sync.c:
Implement working os_sync_wait_time() for POSIX.
storage/xtradb/srv/srv0srv.c:
Make the purge thread wait for an event when sleeping, so we can signal it to
wakeup immediately at shutdown.
plans or wrong results due to the fact that JOIN_CACHE functions
ignored the possibility of interleaving materialized semijoin
tables with tables whose records were stored in join buffers.
This fixes would become mostly unnecessary if the new code of
mwl 90 was merged into 5.3 right now.
Yet the fix the code of optimize_wo_join_buffering was needed
in any case.
- Make optimize_wo_join_buffering() handle cases where position->records_read=0 (this
happens for outer joins that have constant tables inside them). The number of
0 is not correct (should be 1 because outer join will produce at least a NULL-complemented
record) but for now we just make it work with incorrect number.
