Fulltext boolean mode phrase search may crash server on platforms
where size of pointer is not equal to size of unsigned integer
(in other words some 64-bit platforms).
The problem was integer overflow.
Affects 4.1 only.
myisam/ft_boolean_search.c:
my_match_t::beg is unsigned int, that means type of expression
(m[0].beg - 1) has unsigned type too. It may happen that instr()
finds substring in the beggining of passed string, returning
m[0].beg equal to 0. In this case value of expression (m[0].beg - 1)
is equal to MAX_UINT.
This is not a problem on platforms where sizeof(pointer) equals to
sizeof(uint). That means ptr[(uint)-1] = ptr[(uint)MAX_UINT] = ptr - 1.
On some 64-bit platforms where sizeof(pointer) is 8 and sizeof(uint)
is 4, wrong address gets accessed. In other words ptr[(uint)-1] is
equal to ptr + MAX_UINT.
mysql-test/r/fulltext.result:
A test case for BUG#11392.
mysql-test/t/fulltext.test:
A test case for BUG#11392.
ucs2 doesn't provide required by fulltext ctype array. Crash
happens because fulltext attempts to use unitialized ctype
array.
Fixed by converting ucs2 fields to compatible utf8 analogue.
include/my_sys.h:
Added a function to find compatible character set with ctype array
available. Currently used by fulltext search to find compatible
substitute for ucs2 collations.
mysql-test/r/ctype_ucs.result:
A test case for BUG#31159.
mysql-test/t/ctype_ucs.test:
A test case for BUG#31159.
mysys/charset.c:
Added a function to find compatible character set with ctype array
available. Currently used by fulltext search to find compatible
substitute for ucs2 collations.
sql/item_func.cc:
Convert ucs2 fields to utf8. Fulltext requires ctype array, but
ucs2 doesn't provide it.
myisam_sort_buffer_size.
An incorrect length of the sort buffer was used when calculating the
maximum number of keys. When myisam_sort_buffer_size is small enough,
this could result in the number of keys < number of
BUFFPEK structures which in turn led to use of uninitialized BUFFPEKs.
Fixed by correcting the buffer length calculation.
myisam/sort.c:
Use a correct buffer length when calculating the maximum number of keys.
Assert that for each BUFFPEK structure there is at least one
corresponding key. Otherwise we would fail earlier and not reach
merge_buffers().
mysql-test/r/repair.result:
Added a test case for bug #31174.
mysql-test/t/repair.test:
Added a test case for bug #31174.
Bug#28878: InnoDB tables with UTF8 character set and indexes cause wrong result for DML
When making key reference buffers over CHAR fields whitespace (0x20) must be used to fill in the remaining space in the field's buffer. This is what Field_string::store() does. Fixed Field_string::get_key_image() to do the same.
mysql-test/r/innodb_mysql.result:
Bug#28878: test case
mysql-test/t/innodb_mysql.test:
Bug#28878: test case
sql/field.cc:
Bug#28878: Fill with space instead of binary zeros.
DELETE query against memory table with btree index may remove
not all matching rows. This happens only when DELETE uses
index read method to find matching rows. E.g. for queries
like DELETE FROM t1 WHERE a=1.
Fixed by reverting fix for BUG9719 and applying proper solution.
heap/hp_delete.c:
Reverted fix for BUG9719 as it makes queries like
DELETE FROM t1 WHERE a=1 to remove not all matching
rows (assuming this is memory table and there is btree
key over `a`).
This happens because we calculate info->lastkey_len in
heap_rkey(). When we enter heap_rnext(), info->lastkey_len
is 0 (set by hp_rb_delete_key()). We need to preserve
info->lastkey_len in this situation, otherwise
tree_search_key() will always return smallest value in
a tree.
heap/hp_rfirst.c:
If we're performing index_first on a table that was taken from
table cache, info->lastkey_len is initialized to previous query.
Thus we set info->lastkey_len to proper value for subsequent
heap_rnext() calls.
This is needed for DELETE queries only, otherwise this variable is
not used.
Note that the same workaround may be needed for heap_rlast(), but
for now heap_rlast() is never used for DELETE queries.
heap/hp_rnext.c:
An optimization for DELETE queries that use index_first()/index_next().
Use faster tree_search_edge() instead of tree_search_key().
mysql-test/r/heap_btree.result:
A test case for BUG#30590.
mysql-test/t/heap_btree.test:
A test case for BUG#30590.
in get_index_for_order(), don't walk over the end of the index key parts
when matching index description and needed ordering.
mysql-test/r/delete.result:
BUG#30385: Testcase
mysql-test/t/delete.test:
BUG#30385: Testcase
SELECT statement itself returns empty.
As a result of this bug 'SELECT AGGREGATE_FUNCTION(fld) ... GROUP BY'
can return one row instead of an empty result set.
When GROUP BY only has fields of constant tables
(with a single row), the optimizer deletes the group_list.
After that we lose the information about whether we had an
GROUP BY statement. Though it's important
as SELECT min(x) from empty_table; and
SELECT min(x) from empty_table GROUP BY y; have to return
different results - the first query should return one row,
second - an empty result set.
So here we add the 'group_optimized_away' flag to remember this case
when GROUP BY exists in the query and is removed
by the optimizer, and check this flag in end_send_group()
mysql-test/r/group_by.result:
Bug #29717 INSERT INTO SELECT inserts values even if
SELECT statement itself returns empty.
test result
mysql-test/r/insert_select.result:
Bug #29717 INSERT INTO SELECT inserts values even if
SELECT statement itself returns empty.
test result
mysql-test/t/group_by.test:
Bug #29717 INSERT INTO SELECT inserts values even if
SELECT statement itself returns empty.
This is additional testcase that is more basic than the
original bug's testcase and has the same reason.
mysql-test/t/insert_select.test:
Bug #29717 INSERT INTO SELECT inserts values even if
SELECT statement itself returns empty.
test case
sql/sql_select.cc:
Bug #29717 INSERT INTO SELECT inserts values even if
SELECT statement itself returns empty.
Remember the 'GROUP BY was optimized away' case in the JOIN::group_optimized
and check this in the end_send_group()
sql/sql_select.h:
Bug #29717 INSERT INTO SELECT inserts values even if
SELECT statement itself returns empty.
JOIN::group_optimized member added to remember the 'GROUP BY optimied away'
case
This bug manifested itself for join queries with GROUP BY and HAVING clauses
whose SELECT lists contained DISTINCT. It occurred when the optimizer could
deduce that the result set would have not more than one row.
The bug could lead to wrong result sets for queries of this type because
HAVING conditions were erroneously ignored in some cases in the function
remove_duplicates.
mysql-test/r/having.result:
Added a test case for bug #29911.
mysql-test/t/having.test:
Added a test case for bug #29911.
Test case update for bug #29294.
mysql-test/t/loaddata.test:
Test case update for bug #29294.
mysql-test/r/loaddata.result:
Test case update for bug #29294.
The `SELECT 'r' INTO OUTFILE ... FIELDS ENCLOSED BY 'r' ' statement
encoded the 'r' string to a 4 byte string of value x'725c7272'
(sequence of 4 characters: r\rr).
The LOAD DATA statement decoded this string to a 1 byte string of
value x'0d' (ASCII Carriage Return character) instead of the original
'r' character.
The same error also happened with the FIELDS ENCLOSED BY clause
followed by special characters: 'n', 't', 'r', 'b', '0', 'Z' and 'N'.
NOTE 1: This is a result of the undocumented feature: the LOAD DATA INFILE
recognises 2-byte input sequences like \n, \t, \r and \Z in addition
to documented 2-byte sequences: \0 and \N. This feature should be
documented (here backspace character is a default ESCAPED BY character,
in the real-life example it may be any ESCAPED BY character).
NOTE 2, changed behaviour:
Now the `SELECT INTO OUTFILE' statement with the `FIELDS ENCLOSED BY'
clause followed by one of: 'n', 't', 'r', 'b', '0', 'Z' or 'N' characters
encodes this special character itself by doubling it ('r' --> 'rr'),
not by prepending it with an escape character.
sql/sql_class.h:
Fixed bug #29294.
The ESCAPE_CHARS macro constant is defined to enumerate
symbolic names of espace-sequences like '\n', '\t' etc.
The select_export::is_ambiguous_field_sep field has been added
to distinguish special values of the field_sep field from
another values (see ESCAPE_CHARS).
sql/sql_class.cc:
Fixed bug #29294.
The select_export::send_data method has been modified to
encode special values of the field_sep field by
doubling of those values instead of prepending them with a
value of the escape_char field.
Example: The SELECT 'r' INTO OUTFILE FIELDS ENCLOSED BY 'r'
now produces the 'rr' output string instead of x'5c72'
(i.e. instead of sequence of 2 bytes: \ and r).
sql/sql_load.cc:
Fixed bug #29294.
Added commentary for the READ_INFO::unescape method.
mysql-test/t/loaddata.test:
Updated test case for bug #29294.
mysql-test/r/loaddata.result:
Updated test case for bug #29294.
Sometimes special 0 ENUM values was ALTERed to normal
empty string ENUM values.
Special 0 ENUM value has the same string representation
as normal ENUM value defined as '' (empty string).
The do_field_string function was used to convert
ENUM data at an ALTER TABLE request, but this
function doesn't care about numerical "indices" of
ENUM values, i.e. do_field_string doesn't distinguish
a special 0 value from an empty string value.
A new copy function called do_field_enum has been added to
copy special 0 ENUM values without conversion to an empty
string.
sql/field_conv.cc:
Fixed bug #29251.
The Copy_field::get_copy_func method has been modified to
return a pointer to the do_field_enum function if a conversion
between two columns of incompatible enum types is required.
The do_field_enum function has been added for the correct
conversion of special 0 enum values.
mysql-test/t/type_enum.test:
Updated test case for bug #29251.
mysql-test/r/type_enum.result:
Updated test case for bug #29251.
counters from relay
Updated the test to return columns vertically.
mysql-test/r/rpl_change_master.result:
Bug #29116: test updated
mysql-test/t/rpl_change_master.test:
Bug #29116: test updated
- Add test case for this already existing feature
mysql-test/r/mysqltest.result:
Update result file
mysql-test/t/mysqltest.test:
Add test case for this feature
forbid the use of subselect in PURGE LOGS BEFORE command
mysql-test/r/subselect.result:
test result
mysql-test/t/subselect.test:
test case
sql/sql_yacc.yy:
forbid the use of subselect in PURGE LOGS BEFORE command
- Add funtion "query_get_value to allow reading a fields value
into a $variable
client/mysqltest.c:
- Add function "let $var= query_get_value(<query>,<colname>,<row>)"
making it possible to read a value from a specific field in a query
into a $variable.
mysql-test/r/mysqltest.result:
Add test cases for "query_get_value"
mysql-test/t/mysqltest.test:
Add test cases for "query_get_value"
- Final touchups
client/mysqltest.c:
Final touch ups, rename sorted_results to sorted_result
mysql-test/r/mysqltest.result:
Update test result
mysql-test/t/mysqltest.test:
Update results with additional subtests for empty result set,
NULL values and 1024 rows
- Change from "query_sorted <query>" to "sorted_results"
client/mysqltest.c:
Replace "query_sorted <query>" with the ability to turn
on "one shot result sorting" with the command "sorted_results"
mysql-test/r/mysqltest.result:
Update test and result
mysql-test/t/mysqltest.test:
Update test and result
for a query over an empty table right after its creation.
The crash is the result of an attempt made by JOIN::optimize to evaluate
the WHERE condition when no records have been actually read.
The added test case can reproduce the crash only with InnoDB tables and
only with 5.0.x.
mysql-test/r/innodb_mysql.result:
Added a test case for bug #28272.
mysql-test/t/innodb_mysql.test:
Added a test case for bug #28272.
sql/sql_select.cc:
Fixed bug #28272: crash that occurs when running an EXPLAIN command
for a query over an empty table right after its creation.
The crash is the result of an attempt made by JOIN::optimize to evaluate
the WHERE condition when no records have been actually read.
Such attempts could be observed only with EXPLAIN commands.
Now at the optimization phase the WHERE condition is never evaluated if
there is no record previously read from the table.
statement from a UNION query with ORDER BY an expression containing
RAND().
The crash happened because the global order by list in the union query
was not re-initialized for execution.
(Local order by lists were re-initialized though).
mysql-test/r/ps.result:
Added a test case for bug #27937.
mysql-test/t/ps.test:
Added a test case for bug #27937.
sql/sql_union.cc:
Fixed bug #27937: crash for the the second execution of a prepared
statement from a UNION query with ORDER BY an expression containing
RAND().
The crash happened because the global order by list in the union query
was not re-initialized for execution.
(Local order by lists were re-initialized though).
Added re-initialization of the global order by list in the function
st_select_lex_unit::init_prepare_fake_select_lex.
- Queries in the query cache are identified by the individual
characters in the query statement, the current database and
the current environment expressed as a set of system variable
flags.
- Since the set of environment flags didn't properly describe the
current environment unexpected results were returned from the
query cache.
- Query cache is now cleared when the variable ft_boolean_syntax is
updated.
- An identification flag for the variable default_week_format is
added to the query cache record.
Thanks to Martin Friebe who has supplied significant parts of this patch.
mysql-test/r/query_cache.result:
Added test case
mysql-test/t/query_cache.test:
Added test case
sql/mysql_priv.h:
- Added missing flags to reflect the significant local environment
settings of the cached query.
sql/set_var.cc:
- Added query cache flush when system variable ft_boolean_syntax is
updated since this also invalidates all cached result sets using this
variable.
sql/sql_cache.cc:
- Added another local system variable as an identification flag
for cached queries.
When checking for applicability of join cache
we must disable its usage only if there is no
temp table in use.
When a temp table is used we can use join
cache (and it will not make the result-set
unordered) to fill the temp table. The filesort()
operation is then applied to the data in the temp
table and hence is not affected by join cache
usage.
Fixed by narrowing the condition for disabling
join cache to exclude the case where temp table
is used.
mysql-test/r/join.result:
Bug #27531: test case
mysql-test/t/join.test:
Bug #27531: test case
sql/sql_select.cc:
Bug #27531:
Disable join cache only if not using temp table
The generic string to int conversion was used by the Item_func_signed and
the Item_func_unsigned classes to convert DATE/DATETIME values to the
SIGNED/UNSIGNED type. But this conversion produces wrong results for such
values.
Now if the item which result has to be converted can return its result as
longlong then the item->val_int() method is used to allow the item to carry
out the conversion itself and return the correct result.
This condition is checked in the Item_func_signed::val_int() and the
Item_func_unsigned::val_int() functions.
mysql-test/t/cast.test:
Added a test case for the bug#23656: Wrong conversion result of a DATETIME to integer using CAST function.
mysql-test/r/cast.result:
Added a test case for the bug#23656: Wrong conversion result of a DATETIME to integer using CAST function.
sql/item_func.cc:
Bug#23656: Wrong conversion result of a DATETIME to integer using CAST function.
Now if the item which result has to be converted can return its result as
longlong then the item->val_int() method is used to allow the item to carry
out the conversion itself and return the correct result.
This condition is checked in the Item_func_signed::val_int() and the
Item_func_unsigned::val_int() functions.
some rollup rows (rows with NULLs for grouping attributes) if GROUP BY
list contained constant expressions.
This happened because the results of constant expressions were not put
in the temporary table used for duplicate elimination. In fact a constant
item from the GROUP BY list of a ROLLUP query can be replaced for an
Item_null_result object when a rollup row is produced .
Now the JOIN::rollup_init function wraps any constant item referenced in
the GROYP BY list of a ROLLUP query into an Item_func object of a special
class that is never detected as constant item. This ensures creation of
fields for such constant items in temporary tables and guarantees right
results when the result of the rollup operation first has to be written
into a temporary table, e.g. in the cases when duplicate elimination is
required.
mysql-test/r/olap.result:
Added a test case for bug #24856.
mysql-test/t/olap.test:
Added a test case for bug #24856.
sql/item_func.h:
Fixed bug #24856: the result set of a ROLLUP query with DISTINCT could lack
some rollup rows (rows with NULLs for grouping attributes) if GROUP BY
list contained constant expressions.
Itroduced class Item_func_rollup_const derived from Item_func. The object of
this class are never detected as constant items.
We use them for wrapping constant items from the GROUP BY list of any ROLLUP
query. This wrapping allows us to ensure writing constant items into temporary
tables whenever the result of the ROLLUP operation has to be written into a
temporary table, e.g. when ROLLUP is used together with DISTINCT in the SELECT
list.
sql/sql_select.cc:
Fixed bug #24856: the result set of a ROLLUP query with DISTINCT could lack
some rollup rows (rows with NULLs for grouping attributes) if GROUP BY
list contained constant expressions.
Now the JOIN::rollup_init function wraps any constant item referenced in
the GROYP BY list of a ROLLUP query into an Item_func object of a special
class that is never detected as constant item. This ensures creation of
fields for such constant items in temporary tables and guarantees right
results when the result of the rollup operation first has to be written
into a temporary table, e.g. in the cases when duplicate elimination is
required.
INSERT...ON DUPLICATE KEY UPDATE may cause error 1032:
"Can't find record in ..." if we are inserting into
InnoDB table unique index of partial key with
underlying UTF-8 string field.
This error occurs because INSERT...ON DUPLICATE uses a wrong
procedure to copy string fields of multi-byte character sets
for index search.
mysql-test/t/innodb_mysql.test:
Added test case for bug #13191.
mysql-test/r/innodb_mysql.result:
Added test case for bug #13191.
sql/field.h:
Fixed bug #13191.
Field_string::get_key_image() virtual function was overloaded
to implement copying of variable length character (UTF-8) fields.
Field::get_key_image() function prototype has been changed to
return byte size of copied data.
sql/field.cc:
Fixed bug #13191.
Field_string::get_key_image() virtual function was overloaded
to implement copying of variable length character (UTF-8) fields.
Field::get_key_image() function prototype has been changed to
return byte size of copied data.
sql/key.cc:
Fixed bug #13191.
INSERT...ON DUPLICATE KEY UPDATE may cause error 1032:
"Can't find record in ...".
This error occurs because INSERT...ON DUPLICATE uses
a wrong procedure to copy field parts for index search.
key_copy() function has been fixed.
This bug occurs when error message length exceeds allowed limit: my_error()
function outputs "%s" sequences instead of long string arguments.
Formats like %-.64s are very common in errmsg.txt files, however my_error()
function simply ignores precision of those formats.
mysys/my_error.c:
Fixed bug #20710.
This bug occurs when error message length exceeds allowed limit: my_error()
function output "%s" sequences instead of long string arguments.
my_error() function has been fixed to accept formats like %-.64s.
mysql-test/t/alter_table.test:
Added test case for bug #20710.
mysql-test/r/alter_table.result:
Added test case for bug #20710.
on a BLACKHOLE table
Using INSERT DELAYED on BLACKHOLE tables could lead to server
crash.
This happens because delayed thread wants to upgrade a lock,
but BLACKHOLE tables do not have locks at all.
This patch rejects attempts to use INSERT DELAYED on MERGE
tables.
mysql-test/r/blackhole.result:
A test case for BUG#27998.
mysql-test/t/blackhole.test:
A test case for BUG#27998.
sql/ha_blackhole.h:
Removed HA_CAN_INSERT_DELAYED flag from table_flags().
The insert delayed thread upgrades the lock. Hence it is
incapable to handle BLACKHOLE tables, which do not have
locks at all.
