even in the cases when there existed range/index-merge scans that
were cheaper than the full table scan.
This was a defect/bug of the implementation of mwl #128.
Now hash join can work not only with full table scan of the joined
table, but also with full index scan, range and index-merge scans.
Accordingly, in the cases when hash join is used the column 'type'
in the EXPLAINs can contain now 'hash_ALL', 'hash_index', 'hash_range'
and 'hash_index_merge'. If hash join is coupled with a range/index_merge
scan then the columns 'key' and 'key_len' contain info not only on
the used hash index, but also on the indexes used for the scan.
- Linking now with g++ instead of gcc with 'compile-dist' to solve problems with handlersocket/client
- Fixed bug in heap tables when doing handler read next-prev over last row
BUILD/compile-dist:
- Linking now with g++ instead of gcc with 'compile-dist' to solve problems with handlersocket/client
cmd-line-utils/libedit/vi.c:
Fixed compiler warning about not checking return value for write
mysql-test/r/index_intersect.result:
Updated results (missed this file in my last push)
mysql-test/suite/handler/aria.result:
Updated test results
mysql-test/suite/handler/handler.inc:
Changed test to use read next/read prev on key where there are duplicates that can come in different order depending on system
Added testing of read next-prev over last row and read prev-next around first row
mysql-test/suite/handler/heap.result:
Updated test results
mysql-test/suite/handler/init.inc:
More rows to test
mysql-test/suite/handler/innodb.result:
Updated test results
mysql-test/suite/handler/interface.result:
Updated test results
mysql-test/suite/handler/myisam.result:
Updated test results
mysql-test/t/variables-big.test:
Fixed test to not fail on windows
mysql-test/valgrind.supp:
Removed not matching fun: to get rid of valgrind warning
storage/heap/hp_rfirst.c:
Added state so that we know if we have an active position in the index.
storage/heap/hp_rkey.c:
Added state so that we know if we have an active position in the index.
storage/heap/hp_rnext.c:
Handle reading several next after finding the last row (this caused a crash before)
storage/heap/hp_rprev.c:
Handle reading several prev after finding the first row (this caused a crash before)
storage/xtradb/buf/buf0buf.c:
Fixed compiler warning about uninitialized value
dbug/dbug.c:
Fixed compiler warnings on windows
mysql-test/r/index_intersect_innodb.result:
Don't print number of rows as this varies
mysql-test/suite/funcs_1/r/processlist_val_no_prot.result:
Update to use new State
mysql-test/suite/handler/heap.result:
Update results
mysql-test/suite/handler/heap.test:
Changed key used in test as the key 'b' will not guarantee order of the two last elements (as the key value is the same)
mysql-test/suite/pbxt/r/lock_multi.result:
Update to use new State
mysql-test/t/index_intersect.test:
Don't print number of rows as this varies
mysql-test/valgrind.supp:
Added suppression for linux
mysys/hash.c:
Fixed compiler warnings on windows
plugin/handler_socket/handlersocket/database.cpp:
Fixed compiler warnings
sql-common/client_plugin.c:
Changed variable to define to avoid compiler warnings when variable is not used
sql-common/my_time.c:
Initialize all my_time elements to avoid compiler warnings
storage/oqgraph/ha_oqgraph.cc:
Use right function (to avoid compiler warning)
storage/pbxt/src/table_xt.cc:
Initialize variables (to avoid compiler warnings)
Split the tests for MWL#89 into two parts - one for bugs
(currently active), and one for functionality tets
(currently in progress, and thus disabled).
Disable the test for LP BUG#718593.
("-") IN DATABASE NAMES IN ALTER DATABASE.
mysqldump did not quote database name in 'ALTER DATABASE'
statements in its output. This can further cause a failure
while loading if database name contains a hyphen '-'.
This happened as, while printing the 'ALTER DATABASE'
statements, the database name was not quoted.
Fixed by quoting the database name.
client/mysqldump.c:
Bug#11766310 : 59398: MYSQLDUMP 5.1 CAN'T HANDLE A DASH
("-") IN DATABASE NAMES IN ALTER DATABASE.
Modified the print statement in order to print the quoted
database name for 'ALTER DATABASE' statements.
mysql-test/r/mysqldump.result:
Added a test case for bug#11766310.
mysql-test/t/mysqldump.test:
Added a test case for bug#11766310.
- Fixed some issues with partitions and connection_string, which also fixed lp:716890 "Pre- and post-recovery crash in Aria"
- Fixed wrong assert in Aria
Now need to merge with latest xtradb before pushing
sql/ha_partition.cc:
Ensure that m_ordered_rec_buffer is not freed before close.
sql/mysqld.cc:
Changed to use opt_stack_trace instead of opt_pstack.
Removed references to pstack
sql/partition_element.h:
Ensure that connect_string is initialized
storage/maria/ma_key_recover.c:
Fixed wrong assert
sql/multi_range_read.cc:
Added printing of error if something goes wrong in get_next()
(Not critical for this bug fix, but this was something that I noticed while testing and found missing)
storage/myisam/mi_rkey.c:
Fixed wrong error number in mi_yield_and_check_if_killed()
- In Maria/MyISAM: Release/re-acquire locks to give queries that wait on them a chance to make progress
- In Maria/MyISAM: Change from numeric constants to ICP_RES values.
- In Maria: Do check index condition in maria_rprev() (was lost in the merge/backport?)
- In Maria/MyISAM/XtraDB: Check if the query was killed, and return immediately if it was.
Added new storage engine error: HA_ERR_ABORTED_BY_USER, for handler to signal that it detected a kill of the query and aborted
Authors: Sergey Petrunia & Monty
include/my_base.h:
Added HA_ERR_ABORTED_BY_USER, for handler to signal that it detected a kill of the query and aborted
include/my_handler.h:
Added comment
mysql-test/r/myisam_icp.result:
Updated test
mysql-test/t/myisam_icp.test:
Drop used tables at start of test
Added test case that can help with manual testing of killing index condition pushdown query.
mysys/my_handler_errors.h:
Text for new storage engine error
sql/handler.cc:
If engine got HA_ERR_ABORTED_BY_USER, send kill message.
sql/multi_range_read.cc:
Return error code
storage/maria/ha_maria.cc:
Added ma_killed_in_mariadb() to detect kill.
Ensure that file->external_ref points to TABLE object.
storage/maria/ma_extra.c:
Dummy test-if-killed for standalone
storage/maria/ma_key.c:
If ma_check_index_cond() fails, set my_errno and info->cur_row.lastpos
storage/maria/ma_rkey.c:
Release/re-acquire locks to give queries that wait on them a chance to make progress
Check if the query was killed, and return immediately if it was
storage/maria/ma_rnext.c:
Check if the query was killed, and return immediately if it was
Added missing fast_ma_writeinfo(info)
storage/maria/ma_rnext_same.c:
Check if the query was killed, and return immediately if it was
Added missing fast_ma_writeinfo(info)
storage/maria/ma_rprev.c:
Check if the query was killed, and return immediately if it was
Added missing fast_ma_writeinfo(info) and ma_check_index_cond()
storage/maria/ma_search.c:
Give error message if we find a wrong key
storage/maria/ma_static.c:
Added pointer to test-if-killed function
storage/maria/maria_def.h:
New prototypes
storage/myisam/ha_myisam.cc:
Added mi_killed_in_mariadb()
Ensure that file->external_ref points to TABLE object.
storage/myisam/mi_extra.c:
Dummy test-if-killed for standalone
storage/myisam/mi_key.c:
If ma_check_index_cond() fails, set my_errno and info->lastpos
storage/myisam/mi_rkey.c:
Ensure that info->lastpos= HA_OFFSET_ERROR in case of error
Release/re-acquire locks to give queries that wait on them a chance to make progress
Check if the query was killed, and return immediately if it was
Reorder code to do less things in case of error.
Added missing fast_mi_writeinfo()
storage/myisam/mi_rnext.c:
Check if the query was killed, and return immediately if it was
Simplify old ICP code
Added missing fast_ma_writeinfo(info)
storage/myisam/mi_rnext_same.c:
Check if the query was killed, and return immediately if it was
Added missing fast_mi_writeinfo(info)
storage/myisam/mi_rprev.c:
Check if the query was killed, and return immediately if it was
Simplify error handling of ICP
Added missing fast_mi_writeinfo(info)
storage/myisam/mi_search.c:
Give error message if we find a wrong key
storage/myisam/mi_static.c:
Added pointer to test-if-killed function
storage/myisam/myisamdef.h:
New prototypes
storage/xtradb/handler/ha_innodb.cc:
Added DB_SEARCH_ABORTED_BY_USER and ha_innobase::is_thd_killed()
Check if the query was killed, and return immediately if it was
storage/xtradb/handler/ha_innodb.h:
Added prototype
storage/xtradb/include/db0err.h:
Added DB_SEARCH_ABORTED_BY_USER
storage/xtradb/include/row0mysql.h:
Added possible ICP errors
storage/xtradb/row/row0sel.c:
Use ICP errors instead of constants.
Detect if killed and return B_SEARCH_ABORTED_BY_USER
The loop that was looping over subqueries' references to outer field used a
local boolean variable to tell whether the field was grouped or not. But the
implementor failed to reset the variable after each iteration. Thus a field
that was not directly aggregated appeared to be.
Fixed by resetting the variable upon each new iteration.
memory reference
There are two issues present here.
1) There is a possibility that we test a byte beyond the
allocated buffer
2) We compare a byte that might never have been
initalized to see if it's 0.
The first issue is not triggered by existing code, but an
ASSERT has been added to safe-guard against introducing
new code that triggers it.
The second issue is what triggers the Valgrind warnings
reported in the bug report. A buffer is allocated in
class String to hold the value. This buffer is populated
by the character data constituting the string, but is not
zero-terminated in most cases. Testing if it is indeed
zero-terminated means that we check a byte that has never
been explicitly set, thus causing Valgrind to trigger.
Note that issue 2 is not a serious problem. The variable
is read, and if it's not zero, we will set it to zero.
There are no further consequences.
Note that this patch does not fix the underlying problems
with issue 1, as it is deemed too risky to fix at this
point (as noted in the bug report). As discussed in
the report, the c_ptr() method should probably be
replaced, but this requires a thorough analysis of the
~200 calls to the method.
sql/set_var.cc:
These two cases have been reported to fail
with Valgrind.
The patch also adjusts several instable test results
to order the result.
Analysis:
The function prev_record_reads() may skip (jump over)
some query plan nodes where record_count < 1. At the
same time, even though get_partial_join_cost() uses
all first N plan nodes after the last constant table,
it may produce a smaller record_count than
prev_record_reads(), because the record count for
some plan nodes may be < 1, and these nodes may not
participate in prev_record_reads.
Solution:
The current solution is to treat the result of
get_partial_join_cost() as the upper bound for the
total number of unique lookup keys.
attempt to create spatial index on char > 31 bytes".
Attempt to create spatial index on char field with length
greater than 31 byte led to assertion failure on server
compiled with safemutex support.
The problem occurred in mi_create() function which was called
to create a new version of table being altered. This function
failed since it detected an attempt to create a spatial key
on non-binary column and tried to return an error.
On its error path it tried to unlock THR_LOCK_myisam mutex
which has not been not locked at this point. Indeed such an
incorrect behavior was caught by safemutex wrapper and caused
assertion failure.
This patch fixes the problem by ensuring that mi_create()
doesn't releases THR_LOCK_myisam mutex on error path if it was
not acquired.
mysql-test/r/gis.result:
Added test for bug @59888 "debug assertion when attempt to
create spatial index on char > 31 bytes".
mysql-test/t/gis.test:
Added test for bug @59888 "debug assertion when attempt to
create spatial index on char > 31 bytes".
storage/myisam/mi_create.c:
Changed mi_create() not to release THR_LOCK_myisam mutex on
error path if it was not acquired.
This bug extends the fix for LP BUG#715027 to cover one
more case of an Item being transformed, and its property
Item::with_subselect not being updated because
quick_fix_fields doesn't recalculate any properties.
Analysis:
Before calling:
write_record= (select->skip_record(thd) > 0);
the function find_all_keys needs to restore the original read/write
sets of the table that is sorted if the condition select->cond
contains a subquery.
This didn't happen in this test case because the flag "with_subselect"
was not set properly for select->cond.
The reason for the flag not being set properly, was that this condition
was rewritten by add_cond_and_fix() inside make_join_select() by:
/* Add conditions added by add_not_null_conds(). */
if (tab->select_cond)
add_cond_and_fix(thd, &tmp, tab->select_cond);
However, the function add_cond_and_fix() called the shortcut method
Item::quick_fix_field() that didn't update the "with_subselect"
property.
Solution:
Call the complete Item::fix_fields() to update all Item properties,
including "with_subselect".
Analysis:
The failed assert is a result of calling Item_sum_distinct::clear()
on an incomplete object for which Item_sum_distinct::setup() was
not yet called.
The reason is that JOIN::exec for the outer query calls JOIN::reinit()
for all its subqueries, which in turn calls clear() for all aggregate
functions of the subqueries. The call stack is:
mysql_explain_union -> mysql_select -> JOIN::exec -> select_desribe ->
mysql_explain_union -> mysql_select -> JOIN::reinit
This assert doesn't fail in the main 5.3 because constant subqueries
are being executed during the optimize phase of the outer query,
thus the Unique object is created before calling JOIN::exec for the
outer query, and Item_sum_distinct::clear() actually cleans the
Unique object.
Solution:
The best solution is the obvious one - substitute the assert with
a test whether Item_sum_distinct::tree is NULL.
Analysis:
The crash in EXPLAIN resulted from an attempt to print the
name of the internal temporary table created to compute
distinct for the innermost subquery of the test case.
Such tables do not have a corresponding TABLE_LIST (table
reference), hence the crash. The reason for this was that
the subquery was executed as part of constant condition
evaluation before EXPLAIN attempts to print the table name.
During the subquery execution, the subquery JOIN_TAB and
its table are substituted by a temporary table in
make_simple_join.
Solution:
Similar to the analogous case for other Items than the
IS NULL function, do not evaluate expensive constant
conditions.
- Fixed Partition engine to store CONNECTION string for partitions.
Removed HA_NO_PARTITION flag from FederatedX.
Added test 'federated_partition' to suite.
- lp:#585688 - maridb crashes in federatedx code
FederatedX handler instances, created on one thread and used on
another thread (via table cache) when "show table status" is executed
crashed because txn member was not initialized for current thread.
Added test 'federated_bug_585688' to suite.
Author for the patch is Antony Curtis
mysql-test/suite/federated/federated_bug_585688.result:
Test for lp:585688
mysql-test/suite/federated/federated_bug_585688.test:
Test for lp:585688
mysql-test/suite/federated/federated_partition-slave.opt:
Test for partition support in federatedx
mysql-test/suite/federated/federated_partition.result:
Test for partition support in federatedx
mysql-test/suite/federated/federated_partition.test:
Test for partition support in federatedx
mysql-test/t/partition_federated.test:
Updated error message
sql/ha_partition.cc:
Added support for connection strings to partitions for federatedx
sql/ha_partition.h:
Added support for connection strings to partitions for federatedx
sql/partition_element.h:
Added support for connection strings to partitions for federatedx
sql/sql_yacc.yy:
Added support for connection strings to partitions for federatedx
storage/federatedx/ha_federatedx.cc:
Added support for partitions.
FederatedX handler instances, created on one thread and used on another thread (via table cache) when "show table status"
is executed crashed because txn member was not initialized for current thread.
Fixed LP BUG#714808 Assertion `outer_lookup_keys <= outer_record_count'
Analysis:
The function best_access_path() computes the number or records as
follows:
...
if (rec < MATCHING_ROWS_IN_OTHER_TABLE)
rec= MATCHING_ROWS_IN_OTHER_TABLE; // Fix for small tables
...
if (table->quick_keys.is_set(key))
records= (double) table->quick_rows[key];
else
{
/* quick_range couldn't use key! */
records= (double) s->records/rec;
}
Above MATCHING_ROWS_IN_OTHER_TABLE == 10, and s->records == 1,
thus we get an estimated 0.1 records. As a result JOIN::get_partial_join_cost()
for the outer query computes outer_record_count == 0.1 records, which is
meaningless in this context.
Solution:
Round row count estimates that are < 1 to 1.
privileges".
The first problem was that DROP USER didn't properly remove privileges
on stored functions from in-memory structures. So the dropped user
could have called stored functions on which he had privileges before
being dropped while his connection was still around.
Even worse if a new user with the same name was created he would
inherit privileges on stored functions from the dropped user.
Similar thing happened with old user name and function privileges
during RENAME USER.
This problem stemmed from the fact that the handle_grant_data() function
which handled DROP/RENAME USER didn't take any measures to update
in-memory hash with information about function privileges after
updating them on disk.
This patch solves this problem by adding code doing just that.
The second problem was that RENAME USER didn't properly update in-memory
structures describing table-level privileges and privileges on stored
procedures. As result such privileges could have been lost after a rename
(i.e. not associated with the new name of user) and inherited by a new
user with the same name as the old name of the original user.
This problem was caused by code handling RENAME USER in
handle_grant_struct() which [sic!]:
a) tried to update wrong (tables) hash when updating stored procedure
privileges for new user name.
b) passed wrong arguments to function performing the hash update and
didn't take into account the way in which such update could have
changed the order of the hash elements.
This patch solves this problem by ensuring that a) the correct hash
is updated, b) correct arguments are used for the hash_update()
function and c) we take into account possible changes in the order
of hash elements.
mysql-test/r/grant.result:
Added test coverage for bug#36544 "DROP USER does not remove stored
function privileges".
mysql-test/suite/funcs_1/r/innodb_storedproc_06.result:
Since after fixing bug#36544 "DROP USER does not remove stored function
privileges" in-memory structures are correctly updated by DROP USER,
DROP FUNCTION performed after DROP USER for its definer no longer
produces unwarranted warning/error messages.
mysql-test/suite/funcs_1/r/memory_storedproc_06.result:
Since after fixing bug#36544 "DROP USER does not remove stored function
privileges" in-memory structures are correctly updated by DROP USER,
DROP FUNCTION performed after DROP USER for its definer no longer
produces unwarranted warning/error messages.
mysql-test/suite/funcs_1/r/myisam_storedproc_06.result:
Since after fixing bug#36544 "DROP USER does not remove stored function
privileges" in-memory structures are correctly updated by DROP USER,
DROP FUNCTION performed after DROP USER for its definer no longer
produces unwarranted warning/error messages.
mysql-test/t/grant.test:
Added test coverage for bug#36544 "DROP USER does not remove stored
function privileges".
sql/sql_acl.cc:
Changed handle_grant_data() to also update hash with function
privileges. This allows DROP/RENAME USER correctly keep this
in-memory structure up-to-date.
To do this extended handle_grant_struct() to support updating of this
hash. In addition fixed code in this function which is responsible for
handling of column and routine hashes during RENAME USER, ensured that
we correctly update these hashes after changing user name and that we
don't skip elements while iterating through the hash and doing updates.
Also fix bug#59110: Memory leak of QUICK_SELECT_I allocated memory.
Includes Jørgen Lølands review comments.
Root cause of these bugs are that test_if_skip_sort_order() decided to
revert the 'skip_sort_order' descision (and use filesort) after the
query plan has been updated to reflect a 'skip' of the sort order.
This might happen in 'check_reverse_order:' if we have a
select->quick which could not be made descending by appending
a QUICK_SELECT_DESC. ().
The original 'save_quick' was then restored after the QEP has been modified,
which caused:
- An incorrect 'precomputed_group_by= TRUE' may have been set,
and not reverted, as part of the already modifified QEP (Bug#59308)
- A 'select->quick' might have been created which we fail to delete (bug#59110).
This fix is a refactorication of test_if_skip_sort_order() where all logic
related to modification of QEP (controlled by argument 'bool no_changes'), is
moved to the end of test_if_skip_sort_order(), and done after *all* 'test_if_skip'
checks has been performed - including the 'check_reverse_order:' checks.
The refactorication above contains now intentional changes to the logic which
has been moved to the end of the function.
Furthermore, a smaller part of the fix address the handling of the
select->quick objects which may already exists when we call
'test_if_skip_sort_order()' (save_quick) -and
new select->quick's created during test_if_skip_sort_order():
- Before new select->quick may be created by calling ::test_quick_select(), we
set 'select->quick= 0' to avoid that ::test_quick_select() prematurely
delete the save_quick's. (After this call we may have both a 'save_quick'
and 'select->quick')
- All returns from ::test_if_skip_sort_order() where we may have both a
'save_quick' and a 'select->quick' has been changed to goto's to the
exit points 'skiped_sort_order:' or 'need_filesort:' where we
decide which of the QUICK_SELECT's to keep, and delete the other.
with the test case added by this patch.
The bug cannot be reproduced with the same test case for the main
5.3 tree because the backported fix for bug 59696 masks the
problem that causes the crash in the mentioned test case. It's not
clear weather this fix masks this problem in all possible cases.
Anyway the patch for bug 698882 introduced some inconsistent data
structures that could contain indirect references to deleted object.
It happened when two Item_equal objects were merged and the Item_field
list of the second object was joined to such list of the first object.
This operation required adjustment of the backward pointers in
Item fields from the joined list. However the adjustment was missing
and this caused crashes in the tree for mwl#128.
Now the backward pointers are set only when Item_equal items are
completely built and are not changed anymore.
if the standard input is a directory.
The problem is that mysql monitor try to read from stdin without
checking input source type.
The solution is to stop reading data from standard input if a call
to read(2) failed.
A new test case was added into mysql.test.
client/my_readline.h:
Data members error and truncated was added to LINE_BUFFER structure.
These data members used instead of out parameters in functions
batch_readline, intern_read_line.
client/mysql.cc:
read_and_execute() was modified: set status.exit_status to 1
when the error occured while reading the next command line in
non-interactive mode. Also the value of the truncated attribute
of structure LINE_BUFF is taken into account only for non-iteractive mode.
client/readline.cc:
intern_read_line() was modified: cancel reading from input if
fill_buffer() returns -1, e.g. if call to read failed.
batch_readline was modified: set the error data member of LINE_BUFFER
structure to value of my_errno when system error happened during call
to my_read/my_realloc.
mysql-test/t/mysql.test:
Test for bug#57450 was added.
handling.
The problem was that parsing of nested regular expression involved
recursive calls. Such recursion didn't take into account the amount of
available stack space, which ended up leading to stack overflow crashes.
mysql-test/t/not_embedded_server.test:
Added test for bug#58026.
regex/my_regex.h:
added pointer to function as last argument of my_regex_init() for check
enough memory in stack.
regex/regcomp.c:
p_ere() was modified: added call to function for check enough memory
in stack. Function for check available stack space specified by
global variable my_regex_enough_mem_in_stack. This variable set to
NULL for embedded mysqld and to a pointer to function
check_enough_stack_size otherwise.
regex/reginit.c:
my_regex_init was modified: pass a pointer to a function for check
enough memory in stack space. Reset this pointer to NULL in my_regex_end.
sql/mysqld.cc:
Added function check_enough_stack_size() for check enough memory in stack.
Passed this function as second argument to my_regex_init. For embedded
mysqld passed NULL as second argument.
Bug #55755 : Date STD variable signness breaks server on FreeBSD and OpenBSD
* Added a check to configure on the size of time_t
* Created a macro to check for a valid time_t that is safe to use with datetime
functions and store in TIMESTAMP columns.
* Used the macro consistently instead of the ad-hoc checks introduced by 52315
* Fixed compliation warnings on platforms where the size of time_t is smaller than
the size of a long (e.g. OpenBSD 4.8 64 amd64).
Bug #52315: utc_date() crashes when system time > year 2037
* Added a correct check for the timestamp range instead of just variable size check to
SET TIMESTAMP.
* Added overflow checking before converting to time_t.
* Using a correct localized error message in this case instead of the generic error.
* Added a test suite.
* fixed the checks so that they check for unsigned time_t as well. Used the checks
consistently across the source code.
* fixed the original test case to expect the new error code.
Root cause for this bug is that the optimizer try to detect&
optimize the special case:
'<field> BETWEEN c1 AND c1' and handle this as the condition '<field> = c1'
This was implemented inside add_key_field(.. *field, *value[]...)
which assumed field to refer key Field, and value[] to refer a [low...high]
constant pair. value[0] and value[1] was then compared for equality.
In a 'normal' BETWEEN condition of the form '<field> BETWEEN val1 and val2' the
BETWEEN operation is represented with an argementlist containing the
values [<field>, val1, val2] - add_key_field() is then called with
parameters field=<field>, *value=val1.
However, if the BETWEEN predicate specified:
1) '<const1> BETWEEN<const2> AND<field>
the 'field' and 'value' arguments to add_key_field() had to be swapped.
This was implemented by trying to cheat add_key_field() to handle it like:
2) '<const1> GE<const2> AND<const1> LE<field>'
As we didn't really replace the BETWEEN operation with 'ge' and 'le',
add_key_field() still handled it as a 'BETWEEN' and compared the (swapped)
arguments<const1> and<const2> for equality. If they was equal, the
condition 1) was incorrectly 'optimized' to:
3) '<field> EQ <const1>'
This fix moves this optimization of '<field> BETWEEN c1 AND c1' into
add_key_fields() which then calls add_key_equal_fields() to collect
key equality / comparison for the key fields in the BETWEEN condition.
The patch fixed the following optimizer defect: when performing
substitution for best equal fields into where conditions to be
able to do their evaluations as soon as possible the optimizer
skipped conditions over views. That could lead to suboptimal
execution of queries that used views.
Slightly changed the test case to demonstrate the performance
improvements if this fix.
Third updated patch - this version also includes copyright notice in added Perl script.
This patch implements a check for such modules at runtime. If modules are not found or unable to load, the test is skipped with
the following message:
[ skipped ] Test needs Perl modules DBI and DBD::mysql
Checks are done via a helper Perl script which looks for the module in a runtime environment that is as similar to that of the
mysqlhotcopy script as possible (thus not intended for Windows environments at this time).
The helper script tells mysql-test about the result by writing information to a temporary file that is later read by mysql-test.
See comments in added files (have_dbi_dbd-mysql.inc and checkDBI_DBD-mysql.pl) for details.
The patch also removes the mysqlhotcopy tests from the list of disabled tests.
This bug could manifest itself when hash join over a varchar column
with NULL values in some rows was used. It happened because the
function key_buf_cmp erroneously returned FALSE when one of the joined
key fields was null while the second was not.
Also fixed two other bugs in the functions key_hashnr and key_buf_cmp
that could possibly lead to wrong results for some queries that
used hash join over several columns with nulls.
Also reverted the latest addition of the test case for bug #45092. It
had been already backported earlier.