the problem: FORMAT func max_length value was calculated incorrectly
the fix: correct calculation of max_length
mysql-test/r/func_str.result:
test result
mysql-test/t/func_str.test:
test case
sql/item_strfunc.h:
the problem: FORMAT func max_length value was calculated incorrectly
the fix: correct calculation of max_length
show default value for BIT field in printable format
mysql-test/r/type_bit.result:
Bug#35796 SHOW CREATE TABLE and default value for BIT field
test result
mysql-test/t/type_bit.test:
Bug#35796 SHOW CREATE TABLE and default value for BIT field
test case
sql/item.cc:
Bug#35796 SHOW CREATE TABLE and default value for BIT field
issue an error if BIN|HEX deafult value is empty value
(behaviour like for INT fields)
The reason for the failures was bug #21205 (fixed in 6.0 by dtoa, but still present in 5.0/5.1).
mysql-test/r/type_float.result:
Modified the failing test case so that bug #21205 does not occur.
mysql-test/t/type_float.test:
Modified the failing test case so that bug #21205 does not occur.
Bug #41173 rpl_packet fails sporadically on pushbuild: query 'DROP TABLE t1' failed
The both issues appeared to be a race between the SQL thread executing CREATE table t1
and the IO thread that is expected to stop at the consequent big size event.
The two events need serialization which is implemented.
The early bug required back-porting a part fixes for bug#38350 exclusively for 5.0 version.
mysql-test/r/rpl_packet.result:
results changed due to bug#33420, bug#41173.
mysql-test/t/rpl_packet.test:
adding synchronization for sql and io thread (bug#41173 problem).
simplifying the output to show only a relevant info (5.0 sole problem bug#33420).
BUG#39325 Server crash inside MYSQL_LOG::purge_first_log halts replicaiton
The patch reverses the order of the purging and updating events for log and relay-log.info/index files respectively.
This solves the problem of having holes caused by crashes happening between updating info/index files and purging logs.
NOTE: This is a combined patch for BUG#38826 and BUG#39325. This patch is based on bugteam tree and takes into account reviewers suggestions.
bigint' fails on windows.
Visual Studio does not take into account some x86 hardware limitations
which leads to incorrect results when converting large DOUBLE values
to BIGINT UNSIGNED ones.
Fixed by adding a workaround for double->ulonglong conversion on
Windows.
include/config-win.h:
Added double2ulonglong(double) function implementing a workaround for
broken double->ulonglong conversion on Windows/x86.
include/my_global.h:
Define double2ulonglong() as a simple typecast for anything but
Windows.
mysql-test/r/type_float.result:
Added a test case for bug #27483.
mysql-test/t/type_float.test:
Added a test case for bug #27483.
Updated MySQL time handling code to react correctly on UTC leap second additions.
MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc
will return :59:59 instead of :59:60 or 59:61.
As a result the reader will receive :59:59 for 2 or 3 consecutive seconds
during the leap second.
This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds.
But note that when converting the value returned by UNIX_TIMESTAMP() to broken
down time the correction of leap seconds will still be applied.
Note that this fix will make a difference *only* if the OS is specially configured
to return leap seconds from the OS time calls or when using a MySQL time zone
defintion that has leap seconds.
Even after this change date/time literals (or other broken down time
representations) with leap seconds (ending on :59:60 or 59:61) will still be
considered illegal and discarded by the server with an error or
a warning depending on the sql mode.
Added a test case to demonstrate the effect of the fix.
mysql-test/r/timezone3.result:
Bug #39920: test case
mysql-test/std_data/Moscow_leap:
Bug #39920: updated the Moscow time zone to Dr. Olson's tzdata 2008i
to accomodate for the 2008 leap second
mysql-test/t/timezone3.test:
Bug #39920: test case
sql/tztime.cc:
Bug #39920: adjust leap seconds (:60 or :61) to :59
sql/tztime.h:
Bug #39920: adjust leap seconds (:60 or :61) to :59
by using and taking out a full path.
mysql-test/r/ctype_filesystem.result:
Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem-master.opt:
Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem.test:
Bug #37399: use MYSQL_TEST_DIR rooted test
an error
Even after the fix for bug 28701 visible behaviors of
SELECT FROM a view and SELECT FROM a regular table are
little bit different:
1. "SELECT FROM regular table USE/FORCE/IGNORE(non
existent index)" fails with a "ERROR 1176 (HY000):
Key '...' doesn't exist in table '...'"
2. "SELECT FROM view USING/FORCE/IGNORE(any index)" fails
with a "ERROR 1221 (HY000): Incorrect usage of
USE/IGNORE INDEX and VIEW". OTOH "SHOW INDEX FROM
view" always returns empty result set, so from the point
of same behaviour view we trying to use/ignore non
existent index.
To harmonize the behaviour of USE/FORCE/IGNORE(index)
clauses in SELECT from a view and from a regular table the
"ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
and VIEW" message has been replaced with the "ERROR 1176
(HY000): Key '...' doesn't exist in table '...'" message
like for tables and non existent keys.
mysql-test/r/view.result:
Added test case for bug #33461.
Updated test case for bug 28701.
mysql-test/t/view.test:
Added test case for bug #33461.
Updated test case for bug 28701.
sql/sql_view.cc:
Bug #33461: SELECT ... FROM <view> USE INDEX (...) throws
an error
To harmonize the behaviour of USE/FORCE/IGNORE(index)
clauses in SELECT from a view and from a regular table the
"ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
and VIEW" message has been replaced with the "ERROR 1176
(HY000): Key '...' doesn't exist in table '...'" message
like for tables and non existent keys.
The SHOW VARIABLES LIKE .../SELECT @@/SELECT ... FROM INFORMATION_SCHEMA.VARIABLES
were assuming that all the system variables are in system charset (UTF-8).
However the variables that are settable through command line will have a different
character set (character_set_filesystem).
Fixed the server to remember the correct character set of basedir, datadir, tmpdir,
ssl, plugin_dir, slave_load_tmpdir, innodb variables; init_connect and init_slave
variables and use it when processing data.
mysql-test/r/ctype_filesystem.result:
Bug #37339: test case (should be in utf-8)
mysql-test/t/ctype_filesystem-master.opt:
Bug #37339: test case (should be in ISO-8859-1)
mysql-test/t/ctype_filesystem.test:
Bug #37339: test case
sql/mysqld.cc:
Bug #37339: remember the correct character set for init_slave and init_connect
sql/set_var.cc:
Bug #37339:
- remember the character set of the relevant variables
- implement storing and using the correct
character set
sql/set_var.h:
Bug #37339: implement storing and using the correct
character set
sql/sql_show.cc:
Bug #37339: implement storing and using the correct
character set
Certain boolean mode queries with truncation operator did
not return matching records and calculate relevancy
incorrectly.
myisam/ft_boolean_search.c:
Sort ftb->list in ascending order. This helps to fix binary
search in ft_boolean_find_relevance() without rewriting it
much.
Fixed binary search in ft_boolean_find_relevance(), so it finds
right-most element in an array.
Fixed that ft_boolean_find_relevance() didn't return match for
words with truncation operator in case query has other non-
matching words.
mysql-test/r/fulltext.result:
A test case for BUG#37245.
mysql-test/t/fulltext.test:
A test case for BUG#37245.
The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win,
If MySQL is compiled with valgrind there are errors about
using of uninitialized variable(orig_table).
The fix is to set field->orig_table correct value.
mysql-test/r/innodb_mysql.result:
test result
mysql-test/t/innodb_mysql.test:
test case
sql/sql_base.cc:
set field->orig_table to 'table' value because it may be bogus and
it leads to crash on Field_string::type() function.
enable uncacheable flag if we update a view with check option
and check option has a subselect, otherwise, the check option
can be evaluated after the subselect was freed as independent
(See full_local in JOIN::join_free())
mysql-test/r/subselect.result:
test result
mysql-test/t/subselect.test:
test case
sql/mysql_priv.h:
added UNCACHEABLE_CHECKOPTION flag
sql/sql_update.cc:
enable uncacheable flag if we update a view with check option
and check option has a subselect, otherwise, the check option
can be evaluated after the subselect was freed as independent
(See full_local in JOIN::join_free())
extended perror to enable printing of Win32 system errors
extra/perror.c:
extended perror to enable printing of Win32 system errors
mysql-test/r/perror-win.result:
test result
mysql-test/t/perror-win.test:
test case
We pretended that TIMEDIFF() would always return positive results;
this gave strange results in comparisons of the TIMEDIFF(low,hi)<TIME(0)
type that rendered a negative result, but still gave false in comparison.
We also inadvertantly dropped the sign when converting times to
decimal.
CAST(time AS DECIMAL) handles signs of the times correctly.
TIMEDIFF() marked up as signed. Time/date comparison code switched to
signed for clarity.
mysql-test/r/func_sapdb.result:
show that time-related comparisons work with negative
time values now.
show that converting time to DECIMAL no longer drops sign.
mysql-test/t/func_sapdb.test:
show that time-related comparisons work with negative
time values now.
show that converting time to DECIMAL no longer drops sign.
sql/item_cmpfunc.cc:
signed returns
sql/item_cmpfunc.h:
signed now (time/date < > =)
sql/item_func.cc:
signed now
sql/item_timefunc.h:
Functions such as TIMEDIFF() return signed results!
The file-comments pretended we were doing that all along, anyway...
sql/my_decimal.cc:
heed sign when converting time to my_decimal;
times may actually be negative!
Needed for SELECT CAST(time('-73:42:12') AS DECIMAL);
sql/mysql_priv.h:
using signed for dates and times now
ONLY_FULL_GROUP_BY
The check for non-aggregated columns in queries with aggregate function, but without
GROUP BY was treating all the parts of the query as if they are in the SELECT list.
Fixed by ignoring the non-aggregated fields in the WHERE clause.
mysql-test/r/func_group.result:
Bug #39656: test case
mysql-test/t/func_group.test:
Bug #39656: test case
sql/sql_select.cc:
Bug #39656: ignore the new non-aggregated column refs in a WHERE
by saving the state so far and then adding only the new values of the other
parts of the bitmask.
the problem is the same as reported in bug#20835,
so the fix is backport of bug#20835 patch.
mysql-test/r/subselect.result:
test result
mysql-test/t/subselect.test:
test case
returns truncated results
Problem: performig conversion from {INT, DECIMAL, REAL} to CHAR
we incorrectly set its max length in some cases that may lead
to truncated results returned.
Fix: properly set CONVERT({INT, DECIMAL, REAL}, CHAR) result's
max length.
mysql-test/r/ctype_utf8.result:
Fix for bug#36772: When using UTF8, CONVERT with GROUP BY
returns truncated results
- test result.
mysql-test/t/ctype_utf8.test:
Fix for bug#36772: When using UTF8, CONVERT with GROUP BY
returns truncated results
- test case.
sql/item_timefunc.cc:
Fix for bug#36772: When using UTF8, CONVERT with GROUP BY
returns truncated results
- calculating Item_char_typecast::max_length use initial
argument's charset mbmaxlen instead of from_cs->mbmaxlen,
as from_cs may differ in some case (see comment above).
It was possible to crash a mysqld build with EXTRA_DEBUG using
CREATE TABLE ... COMMENT with a specially-crafted UTF-8 string.
This CS removes the check that caused it since it no longer
applies in current servers anyway, and adds comments instead
to avoid future confusion.
mysql-test/r/strict.result:
Try to crash mysqld with a "suitable" multi-byte (3-byte UTF-8) string
for a table comment.
mysql-test/t/strict.test:
Try to crash mysqld with a "suitable" multi-byte (3-byte UTF-8) string
for a table comment.
sql/unireg.cc:
Talk at length about limits in .frm form-info, characters vs bytes,
inlined vs extra-segement TABLE-COMMENTS, and the differences in
6.0+ vs <6.0 when it comes to UTF-8.
Also, remove a check that no longer applies and that could lead to
problems in pathological cases.
The test itself is not faulty. The testcase timeout
problem happens if this IMHO mid size resource
(space in vardir, virtual memory, amount of disk I/O)
consuming test meets a weak (excessive disk I/O caused
by parallel applications or paging) testing box.
The modifications:
- Move the most time and disk I/O consuming subtest
for Bug 1820 into its own script (multi_update2)
This will reduce the likelihood that we exceed the
testcase timeout.
- Replace error numbers with error names
- Minor improvements of the formatting
-
When a CSV file contained comma separated elements
that were not enclosed in quotes, it was causing the
mysql server to crash.
The old algorithm that parsed the content of a row in
mysql 5.0 was assuming that the values of the fields
in a .CSV file will be enclosed in quotes and will be
separated by commas.
This was causing the old algorithm to fail when the
content of the file resembled the following
3,"sans quotes"
The CSV engine that is part of mysql 5.0 was expecting
the above to be
"3","sans quotes"
The above is just one example of where the engine was
failing for what would be recognized as a valid .CSV
file content otherwise.
The proposed fix changes the old algorithm being used
to parse rows from the .CSV file to handle two separate
cases
1) When the current field of the row is enclosed in quotes
2) When the current field of the row is not enclosed in
quotes
mysql-test/r/csv.result:
Contains additional test output corresponding to the new
tests added.
mysql-test/t/csv.test:
Contains additional tests for testing the behaviour of the CSV
storage engine when the fields are not enclosed in quotes.
sql/examples/ha_tina.cc:
Changes the parsing logic of the rows in a CSV file to account for
fields that are not enclosed in quotes.
Item_func_div didn't calculate the precision of the result properly.
The result of 5/0.0001 is 5000 so we have to add decimals of the divisor
to the planned precision.
per-file comments:
mysql-test/r/type_newdecimal.result
Bug#31616 div_precision_increment description looks wrong
test result fixed
mysql-test/t/type_newdecimal.test
Bug#31616 div_precision_increment description looks wrong
test case
sql/item_func.cc
Bug#31616 div_precision_increment description looks wrong
precision must be increased with args[1]->decimals parameter
tables can cause server to crash!
The bug will be fixed by patch for #34779: "crash in checksum table
on federated tables with blobs containing nulls"
Only a test case commited.
mysql-test/r/federated.result:
Test case for bug #34774: key prefix on text field in federated
tables can cause server to crash!
- test result.
mysql-test/t/federated.test:
Test case for bug #34774: key prefix on text field in federated
tables can cause server to crash!
- test case.
when InnoDB frm file corruption
Problem: mysqlcheck runs 'SHOW FULL TABLE' queries to get table lists.
The query may fail for some reasons (e.g. null .frm file) then
mysqlcheck doesn't process the database tables.
Fix: try to run 'SHOW TABLES' if 'SHOW FULL TABLES' failed.
client/mysqlcheck.c:
Fix for bug#37527: mysqlcheck fails to report entire database
when InnoDB frm file corruption
- run "SHOW TABLES" query if "SHOW /*!50002 FULL*/ TABLES" failed;
- print error info if both failed.
mysql-test/r/mysqlcheck.result:
Fix for bug#37527: mysqlcheck fails to report entire database
when InnoDB frm file corruption
- test result.
mysql-test/t/mysqlcheck.test:
Fix for bug#37527: mysqlcheck fails to report entire database
when InnoDB frm file corruption
- test case.
issue 'The storage engine for the table doesn't support check' note for I_S tables
mysql-test/r/mysqlcheck.result:
test result
mysql-test/t/mysqlcheck.test:
test case
sql/sql_table.cc:
issue 'The storage engine for the table doesn't support check' note for I_S tables
With fix for bug 25951 index hints are ignored for fulltext
searches, as handling of fulltext indexes is different from
handling regular indexes. Meaning it is not possible to
implement true index hints support for fulltext indexes within
the scope of current fulltext architecture.
The problem is that prior to fix for bug 25951, some useful
index hints still could be given for boolean mode searches.
This patch implements special index hints support for fulltext
indexes with the following characteristics:
- all index hints are still ignored for NLQ mode searches -
it cannot work without an index;
- for 5.1 and up index hints FOR ORDER BY and FOR GROUP BY are
still ignored for fulltext indexes;
- boolean mode searches honor USE/FORCE/IGNORE INDEX hints;
- as opposed to index hints for regular indexes, index hints
for fulltext BOOLEAN mode searches affect the usage of the
index for the whole query.
mysql-test/r/fulltext.result:
A test case for BUG#38842.
mysql-test/t/fulltext.test:
A test case for BUG#38842.
sql/item_func.cc:
For boolean mode searches, which can work without fulltext
index, use keys_in_use_for_query bitmap instead of keys_in_use.
The effect is that boolean mode searches now honor index hints.
implicit command which isn't completed immediately.
mysql-test/r/status2.result:
* Moved disconnect command to avoid race.
mysql-test/t/status2.test:
* Moved disconnect command to avoid race.
A string buffers which were included in the 'view' data structure
were allocated on the stack, causing an invalid pointer when used
after the function returned.
The fix: use copy of values for view->md5 & view->queries
mysql-test/r/view.result:
test result
mysql-test/t/view.test:
test case
sql/sql_view.cc:
A string buffers which were included in the 'view' data structure
were allocated on the stack, causing an invalid pointer when used
after the function returned.
The fix: use copy of values for view->md5 & view->queries
- Make send_row_on_empty_set() return FALSE when simplify_cond() has found out
that HAVING is always FALSE
re-committing to put the fix into 5.0 and 5.1
mysql-test/r/group_by.result:
BUG#38072: Wrong result: HAVING not observed in a query with aggregate
- Testcase
mysql-test/t/group_by.test:
BUG#38072: Wrong result: HAVING not observed in a query with aggregate
- Testcase
sql/sql_select.h:
BUG#38072: Wrong result: HAVING not observed in a query with aggregate
- Make send_row_on_empty_set() return FALSE when simplify_cond() has found out
that HAVING is always FALSE
The problem was that the server did not robustly handle a
unilateral roll back issued by the Resource Manager (RM)
due to a resource deadlock within the transaction branch.
By not acknowledging the roll back, the server (TM) would
eventually corrupt the XA transaction state and crash.
The solution is to mark the transaction as rollback-only
if the RM indicates that it rolled back its branch of the
transaction.
mysql-test/r/xa.result:
Add test case result for Bug#28323
mysql-test/t/xa.test:
Add test case for Bug#28323
sql/handler.cc:
Reset XID only at the end of the global transaction.
sql/share/errmsg.txt:
Add new error codes.
sql/sql_class.h:
Remember the error reported by the Resource Manager.
sql/sql_parse.cc:
Rollback the transaction if the Resource Manager reported
a error and rolled back its branch of the transaction.
The problem was that the server did not robustly handle a
unilateral roll back issued by the Resource Manager (RM)
due to a resource deadlock within the transaction branch.
By not acknowledging the roll back, the server (TM) would
eventually corrupt the XA transaction state and crash.
The solution is to mark the transaction as rollback-only
if the RM indicates that it rolled back its branch of the
transaction.
mysql-test/r/xa.result:
Add test case result for Bug#28323
mysql-test/t/xa.test:
Add test case for Bug#28323
sql/handler.cc:
Reset XID only at the end of the global transaction.
sql/share/errmsg.txt:
Add new error codes.
sql/sql_class.h:
Remember the error reported by the Resource Manager.
sql/sql_parse.cc:
Rollback the transaction if the Resource Manager reported
a error and rolled back its branch of the transaction.
fails after the first time
Two separate problems :
1. When flattening joins the linked list used for name resolution
(next_name_resolution_table) was not updated.
Fixed by updating the pointers when extending the table list
2. The items created by expanding a * (star) as a column reference
were marked as fixed, but no cached table was assigned to them
(unlike what Item_field::fix_fields does).
Fixed by assigning a cached table (so the re-preparation is done
faster).
Note that the fix for #2 hides the fix for #1 in most cases
(except when a table reference cannot be cached).
mysql-test/r/sp.result:
Bug #33811: test case
mysql-test/t/sp.test:
Bug #33811: test case
sql/sql_base.cc:
Bug #33811: cache the table for Item_fields created by expanding '*'
sql/sql_select.cc:
Bug #33811: maintain a correct name resolution chain when
flattening joins.
IS NULL was not checking the correct row in a HAVING context.
At the first row of a new group (where the HAVING clause is evaluated)
the column and SELECT list references in the HAVING clause should
refer to the last row of the previous group and not to the current one.
This was not done for IS NULL, because it was using Item::is_null() doesn't
have a Item_is_null_result() counterpart to access the data from the
last row of the previous group. Note that all the Item::val_xxx() functions
(e.g. Item::val_int()) have their _result counterparts (e.g. Item::val_int_result()).
Fixed by implementing a is_null_result() (similarly to int_result()) and
calling this instead of is_null() column and SELECT list references inside
the HAVING clause.
mysql-test/r/having.result:
Bug #38637: test case
mysql-test/t/having.test:
Bug #38637: test case
sql/item.cc:
Bug #38637: implement Item::is_null_result() and call it
from Item_ref and Item_field as appropriate.
sql/item.h:
Bug #38637: implement Item::is_null_result() and call it
from Item_ref and Item_field as appropriate.
sql/item_func.cc:
Bug #38637: implement Item::is_null_result() and call it
from Item_ref and Item_field as appropriate.
sql/item_func.h:
Bug #38637: implement Item::is_null_result() and call it
from Item_ref and Item_field as appropriate.
Server crashed during a sort order optimization
of a dependent subquery:
SELECT
(SELECT t1.a FROM t1, t2
WHERE t1.a = t2.b AND t2.a = t3.c
ORDER BY t1.a)
FROM t3;
Bitmap of tables, that the reference to outer table
column uses, in addition to the regular table bit
has the OUTER_REF_TABLE_BIT bit set.
The only_eq_ref_tables function traverses this map
bit by bit simultaneously with join->map2table list.
Obviously join->map2table never contains an entry
for the OUTER_REF_TABLE_BIT pseudo-table, so the
server crashed there.
The only_eq_ref_tables function has been modified
to traverse regular table bits only like the
update_depend_map function (resetting of the
OUTER_REF_TABLE_BIT there is enough, but
resetting of the whole set of PSEUDO_TABLE_BITS
is used there for sure).
mysql-test/r/order_by.result:
Added test case for bug #39844.
mysql-test/t/order_by.test:
Added test case for bug #39844.
sql/sql_select.cc:
Bug #39844: Query Crash Mysql Server 5.0.67
The only_eq_ref_tables function has been modified
to traverse regular table bits only like the
update_depend_map function (resetting of the
OUTER_REF_TABLE_BIT there is enough, but
resetting of the whole set of PSEUDO_TABLE_BITS
is used there for sure).
Added the missing DROP TABLE
mysql-test/r/windows.result:
Bug #39958: added the missing DROP TABLE
mysql-test/t/windows.test:
Bug #39958: added the missing DROP TABLE
The problem is that the offset argument of the limit clause
might be truncated on a 32-bits server built without big
tables support. The truncation was happening because the
original 64-bits long argument was being cast to a 32-bits
(ha_rows) offset counter.
The solution is to check if the conversing resulted in value
truncation and if so, the offset is set to the maximum possible
value that can fit on the type.
mysql-test/r/limit.result:
Add test case result for Bug#37075
mysql-test/t/limit.test:
Add test case for Bug#37075
sql/sql_lex.cc:
Check for truncation of the offset value. If value was
truncated, set to the maximum possible value.
The problem is that field names constructed due to wild-card
expansion done inside a stored procedure could point to freed
memory if the expansion was performed after the first call to
the stored procedure.
The problem was solved by patch for Bug#38691. The solution
was to allocate the database, table and field names in the
in the statement memory instead of table memory.
mysql-test/r/sp.result:
Add test case result for Bug#38823
mysql-test/t/sp.test:
Add test case for Bug#38823
sql/item.cc:
Remark that this also impacts wildcard expansion inside SPs.
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).
mysql-test/r/subselect3.result:
Added test case for bug #37894.
mysql-test/t/subselect3.test:
Added test case for bug #37894.
sql/opt_range.cc:
Bug #37894: Assertion in init_read_record_seq in handler.h line 1444
Unnecessary index initialization has been removed from
the QUICK_RANGE_SELECT::init method (QUICK_RANGE_SELECT::reset
reinvokes this initialization).
with COALESCE and JOIN
The server returned to a client the VARBINARY column type
instead of the DATE type for a result of the COALESCE,
IFNULL, IF, CASE, GREATEST or LEAST functions if that result
was filesorted in an anonymous temporary table during
the query execution.
For example:
SELECT COALESCE(t1.date1, t2.date2) AS result
FROM t1 JOIN t2 ON t1.id = t2.id ORDER BY result;
To create a column of various date/time types in a
temporary table the create_tmp_field_from_item() function
uses the Item::tmp_table_field_from_field_type() method
call. However, fields of the MYSQL_TYPE_NEWDATE type were
missed there, and the VARBINARY columns were created
by default.
Necessary condition has been added.
mysql-test/r/metadata.result:
Added test case for bug #39283.
mysql-test/t/metadata.test:
Added test case for bug #39283.
sql/sql_select.cc:
Bug #39283: Date returned as VARBINARY to client for queries
with COALESCE and JOIN
To create a column of various date/time types in a
temporary table the create_tmp_field_from_item() function
uses the Item::tmp_table_field_from_field_type() method
call. However, fields of the MYSQL_TYPE_NEWDATE type were
missed there, and the VARBINARY columns were created
by default.
Necessary condition has been added.
derived table cause crash
When a multi-UPDATE command fails to lock some table, and
subsequently succeeds, the tables need to be reopened if
they were altered. But the reopening procedure failed for
derived tables.
Extra cleanup has been added.
mysql-test/r/lock_multi.result:
Added test case for bug #38499.
mysql-test/t/lock_multi.test:
Added test case for bug #38499.
sql/sql_union.cc:
Bug#38499: flush tables and multitable table update with
derived table cause crash
Obsolete assertion has been removed.
sql/sql_update.cc:
Bug#38499: flush tables and multitable table update with
derived table cause crash
Extra cleanup for derived tables has been added:
1) unit.cleanup(),
2) unit->reinit_exec_mechanism().
When running Stored Routines the Status Variable "Questions" was wrongly
incremented. According to the manual it should contain the "number of
statements that clients have sent to the server"
Introduced a new status variable 'questions' to replace the query_id
variable which currently corresponds badly with the number of statements
sent by the client.
The new behavior is ment to be backward compatible with 4.0 and at the
same time work with new features in a similar way.
This is a backport from 6.0
mysql-test/r/status2.result:
Added test case
mysql-test/t/status2.test:
Added test case
sql/mysqld.cc:
Introduced a new status variable 'questions' to replace the query_id
variable which currently corresponds badly with the number of statements
sent by the client.
sql/sql_class.h:
Introduced a new status variable 'questions' to replace the query_id
variable which currently corresponds badly with the number of statements
sent by the client.
sql/sql_parse.cc:
To be backward compatible with 4.0 and at the same time extend the
interpretation of the Question variable, it should be increased on
all COM-commands but COM_STATISTICS, COM_PING, COM_STMT_PREPARE,
COM_STMT_CLOSE and COM_STMT_RESET.
Since COM_QUERY can process multiple statements, there has to be an
extra increase there as well.
sql/sql_show.cc:
Removed deprecated SHOW_QUESTION status code.
sql/structs.h:
Removed deprecated SHOW_QUESTION status code.
``FLUSH TABLES WITH READ LOCK''
Concurrent execution of 1) multitable update with a
NATURAL/USING join and 2) a such query as "FLUSH TABLES
WITH READ LOCK" or "ALTER TABLE" of updating table led
to a server crash.
The mysql_multi_update_prepare() function call is optimized
to lock updating tables only, so it postpones locking to
the last, and if locking fails, it does cleanup of modified
syntax structures and repeats a query analysis. However,
that cleanup procedure was incomplete for NATURAL/USING join
syntax data: 1) some Field_item items pointed into freed
table structures, and 2) the TABLE_LIST::join_columns fields
was not reset.
Major change:
short-living Field *Natural_join_column::table_field has
been replaced with long-living Item*.
mysql-test/r/lock_multi.result:
Added test case for bug #38691.
mysql-test/t/lock_multi.test:
Added test case for bug #38691.
sql/item.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
The Item_field constructor has been modified to allocate
and copy original database/table/field names always (not
during PS preparation/1st execution only), because
an initialization of Item_field items with a pointer to
short-living Field structures is a common practice.
sql/sql_base.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
1) Type adjustment for Natural_join_column::table_field
(Field to Item_field);
2) The setup_natural_join_row_types function has been
updated to take into account new
first_natural_join_processing flag to skip unnecessary
reinitialization of Natural_join_column::join_columns
during table reopening after lock_tables() failure
(like the 'first_execution' flag for PS).
sql/sql_lex.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
Initialization of the new
st_select_lex::first_natural_join_processing flag has
been added.
sql/sql_lex.h:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
The st_select_lex::first_natural_join_processing flag
has been added to skip unnecessary rebuilding of
NATURAL/USING JOIN structures during table reopening
after lock_tables failure.
sql/sql_update.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
Extra cleanup calls have been added to reset
Natural_join_column::table_field items.
sql/table.cc:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
Type adjustment for Natural_join_column::table_field
(Field to Item_field).
sql/table.h:
Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
``FLUSH TABLES WITH READ LOCK''
Type of the Natural_join_column::table_field field has
been changed from Field that points into short-living
TABLE memory to long-living Item_field that can be
linked to (fixed) reopened table.
The '@' symbol can not be used in the host name according to rfc952.
The fix:
added function check_host_name(LEX_STRING *str)
which checks that all symbols in host name string are valid and
host name length is not more than max host name length
(just moved check_string_length() function from the parser into check_host_name()).
mysql-test/r/create.result:
test result
mysql-test/t/create.test:
test case
sql/mysql_priv.h:
added function check_host_name(LEX_STRING *str)
sql/sql_parse.cc:
added function check_host_name(LEX_STRING *str)
which checks that all symbols in host name string are valid and
host name length is not more than max host name length(HOSTNAME_LENGTH).
sql/sql_yacc.yy:
using newly added function check_host_name()
The problem:
I_S views table does not check the presence of SHOW_VIEW_ACL|SELECT_ACL
privileges for a view. It leads to discrepancy between SHOW CREATE VIEW
and I_S.VIEWS.
The fix:
added appropriate check.
mysql-test/r/information_schema_db.result:
test result
mysql-test/t/information_schema_db.test:
test case
sql/sql_show.cc:
The problem:
I_S views table does not check the presence of SHOW_VIEW_ACL|SELECT_ACL
privileges for a view. It leads to discrepancy between SHOW CREATE VIEW
and I_S.VIEWS.
The fix:
added appropriate check.
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.
mysql-test/r/index_merge.result:
Bug#37943: test case
mysql-test/t/index_merge.test:
Bug#37943: test case
sql/opt_range.cc:
Bug#37943:
- Make copy constructors for SEL_TREE and sub-structures and use them when OR-ing trees.
- don't generate empty SEL_TREEs. Return NULL instead.
from stored procedure.
Problem: we replace all references to local variables in stored procedures
with NAME_CONST(name, value) logging to the binary log. However, if the
value's collation differs we might get an 'illegal mix of collation'
error as we don't pass the collation to the function.
Fix: pass the value's collation to NAME_CONST().
Note: actually we should pass to NAME_CONST() the value's derivation as well.
It's impossible without the parser modifying. Now we always set the
derivation to DERIVATION_IMPLICIT, the same as local variables have.
mysql-test/r/binlog.result:
Fix for bug#39182: Binary log producing incompatible character set query
from stored procedure.
- test result.
mysql-test/r/ctype_cp932_binlog.result:
Fix for bug#39182: Binary log producing incompatible character set query
from stored procedure.
- results adjusted.
mysql-test/r/rpl_sp.result:
Fix for bug#39182: Binary log producing incompatible character set query
from stored procedure.
- results adjusted.
mysql-test/t/binlog.test:
Fix for bug#39182: Binary log producing incompatible character set query
from stored procedure.
- test case.
sql/item.cc:
Fix for bug#39182: Binary log producing incompatible character set query
from stored procedure.
- allow NAME_CONST() to get _charset'foo' COLLATE 'bar' strings
(see Item_func_set_collation).
sql/sp_head.cc:
Fix for bug#39182: Binary log producing incompatible character set query
from stored procedure.
- pass the value's collation to NAME_CONST().
JOIN for the subselect wasn't cleaned if we came upon an error
during sub_select() execution. That leads to the assertion failure
in close_thread_tables()
part of the 6.0 code backported
per-file comments:
mysql-test/r/sp-error.result
Bug#37949 Crash if argument to SP is a subquery that returns more than one row
test result
mysql-test/t/sp-error.test
Bug#37949 Crash if argument to SP is a subquery that returns more than one row
test case
sql/sp_head.cc
Bug#37949 Crash if argument to SP is a subquery that returns more than one row
lex->unit.cleanup() call added if not substatement
Machines with hostname set to "localhost" cause uniqueness errors in
the SQL bootstrap data.
Now, insert zero lines for cases where the (lowercased) hostname is
the same as an already-inserted 'localhost' name. Also, fix a few tests
that expect certain local accounts to have a certain host name.
A stored procedure involving substrings could crash the server on certain
platforms because of invalid memory reads.
During storing the new blob-field value, the cached value's address range
overlapped that of the new field value. This caused problems when the
cached value storage was reallocated to provide access for a new
characater set representation. The patch checks the address ranges, and if
they overlap, the new field value is copied to a new storage before it is
converted to the new character set.
mysql-test/r/sp.result:
Added result set
mysql-test/t/sp.test:
Added test case
sql/field.cc:
The source and destination address ranges of a character conversion must not overlap or the 'from' address will be invalidated as the temporary value-
object is re-allocated to fit the new character set.
sql/field.h:
Added comments
The fix for bug 31887 was incomplete : it assumes that all the
field types returned by the IS_NUM macro are descendants of
Item_num and tries to zero-fill the values before doing constant
substitution with such fields when they are compared to constant string
values.
The only exception to this is Field_timestamp : it's in the IS_NUM
macro, but is not a descendant of Field_num.
Fixed by excluding timestamp fields (Field_timestamp) when zero-filling
when converting the constant to compare with to a string.
Note that this will not exclude the timestamp columns from const
propagation.
mysql-test/r/compare.result:
Bug #39353: test case
mysql-test/t/compare.test:
Bug #39353: test case
sql/item.cc:
Bug #39353: don't zero-fill timestamp fields when const propagating
to a string : they'll be converted to a string in a date/time format
and not as an integer.
NO_BACKSLASH_ESCAPES was not heeded in LOAD DATA INFILE
and SELECT INTO OUTFILE. It is now.
mysql-test/r/loaddata.result:
Show that SQL-mode NO_BACKSLASH_ESCAPES is heeded in
INFILE/OUTFILE, and that dump/restore cycles work!
mysql-test/t/loaddata.test:
Show that SQL-mode NO_BACKSLASH_ESCAPES is heeded in
INFILE/OUTFILE, and that dump/restore cycles work!
sql/sql_class.cc:
Add function to enquire whether ESCAPED BY was given.
When doing SELECT...OUTFILE, use ESCAPED BY if specifically
given; otherwise use sensible default value depending on
SQL-mode features NO_BACKSLASH_ESCAPES.
sql/sql_class.h:
Add function to enquire whether ESCAPED BY was given.
sql/sql_load.cc:
When doing LOAD DATA INFILE, use ESCAPED BY if specifically
given; otherwise use sensible default value depending on
SQL-mode features NO_BACKSLASH_ESCAPES.
Details:
- backport of some improvements which prevent sporadic
failures from 5.1 to 5.0
- @@GLOBAL.CONCURRENT_INSERT= 0 also for slave server
- --sorted_result before all selects which have result
sets with more than one row
- Replace error numbers by error names
Moved fix for this bug to 5.0 as other mysqldump bugs seem tied to concurrent_insert being on
Setting concurrent_insert off during this test as INSERTs weren't being
completely processed before the calls to mysqldump, resulting in failing tests.
Altered .test file to turn concurrent_insert off during the test and to restore it
to whatever the value was at the start of the test when complete.
Re-recorded .result file to account for changes to variables in the test.
mysqldump creates stand-in tables before dumping the actual view.
Those tables were of the default type; if the view had more columns
than that (a pathological case, arguably), loading the dump would
fail. We now make the temporary stand-ins MyISAM tables to prevent
this.
client/mysqldump.c:
When creating a stand-in table, specify its type to
avoid defaulting to a type with a column-number limit
(like Inno). The type is always MyISAM as we know that
to be available.
mysql-test/r/mysqldump.result:
mysqldump sets engine-type (MyISAM) for stand-in tables
for views now. Update test results.
Problem: <=> operator may return wrong results
comparing NULL and a DATE/DATETIME/TIME value.
Fix: properly check NULLs.
mysql-test/r/type_datetime.result:
Fix for bug#37526: asymertic operator <=> in trigger
- test result.
mysql-test/t/type_datetime.test:
Fix for bug#37526: asymertic operator <=> in trigger
- test case.
sql/item_cmpfunc.cc:
Fix for bug#37526: asymertic operator <=> in trigger
- if is_nulls_eq is TRUE Arg_comparator::compare_datetime()
should return 1 only if both arguments are NULL.
Problem: SELECT ... REGEXP BINARY NULL may lead to server crash/hang.
Fix: properly handle NULL regular expressions.
mysql-test/r/func_regexp.result:
Fix for bug #39021: SELECT REGEXP BINARY NULL never returns
- test result.
mysql-test/t/func_regexp.test:
Fix for bug #39021: SELECT REGEXP BINARY NULL never returns
- test case.
sql/item_cmpfunc.cc:
Fix for bug #39021: SELECT REGEXP BINARY NULL never returns
- checking regular expressions' null_value
we tested it without a val_xxx() call before, which is wrong.
Now Item_func_regex::regcomp() returns -1 in the case
and allows to handle NULL expessions properly.
sql/item_cmpfunc.h:
Fix for bug #39021: SELECT REGEXP BINARY NULL never returns
- checking regular expressions' null_value
we tested it without a val_xxx() call before, which is wrong.
Now Item_func_regex::regcomp() returns -1 in the case
and allows to handle NULL expessions properly.
in open_table()
Problem: repeating "CREATE... ( AUTOINCREMENT) ... SELECT" may lead to
an assertion failure.
Fix: reset table->auto_increment_field_not_null after each record
writing.
mysql-test/r/create.result:
Fix for bug#38821: Assert table->auto_increment_field_not_null failed
in open_table()
- test result.
mysql-test/t/create.test:
Fix for bug#38821: Assert table->auto_increment_field_not_null failed
in open_table()
- test case.
sql/sql_insert.cc:
Fix for bug#38821: Assert table->auto_increment_field_not_null failed
in open_table()
- reset table->auto_increment_field_not_null after writing a record
for "{CREATE, INSERT}..SELECT".
INSERT .. SELECT .. ON DUPLICATE KEY UPDATE col=DEFAULT
In order to get correct values from update fields that
belongs to the SELECT part in the INSERT .. SELECT .. ON
DUPLICATE KEY UPDATE statement, the server adds referenced
fields to the select list. Part of the code that does this
transformation is shared between implementations of
the DEFAULT(col) function and the DEFAULT keyword (in
the col=DEFAULT expression), and an implementation of
the DEFAULT keyword is incomplete.
mysql-test/r/default.result:
Added test case for bug #39002.
mysql-test/t/default.test:
Added test case for bug #39002.
sql/item.cc:
The Item_default_value::transform() function has been
modified to take into account the fact that the DEFAULT
keyword has no arguments unlike the DEFAULT(col) function
that always has an argument.
returns unexpected result
If:
1. a table has a not nullable BIT column c1 with a length
shorter than 8 bits and some additional not nullable
columns c2 etc, and
2. the WHERE clause is like: (c1 = constant) AND c2 ...,
the SELECT query returns unexpected result set.
The server stores BIT columns in a tricky way to save disk
space: if column's bit length is not divisible by 8, the
server places reminder bits among the null bits at the start
of a record. The rest bytes are stored in the record itself,
and Field::ptr points to these rest bytes.
However if a bit length of the whole column is less than 8,
there are no remaining bytes, and there is nothing to store in
the record at its regular place. In this case Field::ptr points
to bytes actually occupied by the next column in a record.
If both columns (BIT and the next column) are NOT NULL,
the Field::eq function incorrectly deduces that this is the
same column, so query transformation/equal item elimination
code (see build_equal_items_for_cond) may mix these columns
and damage conditions containing references to them.
mysql-test/r/type_bit.result:
Added test case for bug #37799.
mysql-test/t/type_bit.test:
Added test case for bug #37799.
sql/field.h:
1. The Field::eq function has been modified to take types of
comparing columns into account to distinguish between BIT and
not BIT columns referencing the same bytes in a record.
2. Unnecessary type comparison has been removed from the
Field_bit::eq function (moved to Field::eq).
used causes server crash.
When the loose index scan access method is used values of aggregated functions
are precomputed by it. Aggregation of such functions shouldn't be performed
in this case and functions should be treated as normal ones.
The create_tmp_table function wasn't taking this into account and this led to
a crash if a query has MIN/MAX aggregate functions and employs temporary table
and loose index scan.
Now the JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate
functions as normal ones when the loose index scan is used.
mysql-test/r/group_min_max.result:
Added a test case for the bug#38195.
mysql-test/t/group_min_max.test:
Added a test case for the bug#38195.
sql/sql_select.cc:
Bug#38195: Incorrect handling of aggregate functions when loose index scan is
used causes server crash.
The JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate
functions as normal ones when the loose index scan is used.
Problem: data consistency check (maximum record length) for a correct
MyISAM table with CHECKSUM=1 and ROW_FORMAT=DYNAMIC option
may fail due to wrong inner MyISAM parameter. In result we may
have the table marked as 'corrupted'.
Fix: properly set MyISAM maximum record length parameter.
myisam/mi_create.c:
Fix for bug #37310: 'on update CURRENT_TIMESTAMP' option crashes the table
Use HA_OPTION_PACK_RECORD instead of HA_PACK_RECORD (typo?)
calculating packed record length.
Send_field.org_col_name has broken value on secondary execution.
It happens when result field is created from the field which belongs to view
due to forgotten assignment of some Send_field attributes.
The fix:
set Send_field.org_col_name,org_table_name with correct value during Send_field intialization.
mysql-test/r/metadata.result:
result fix
The result file was changed because now forgotten attributes are properly set.
mysql-test/r/sp.result:
test result
mysql-test/t/sp.test:
test case
sql/item.cc:
Send_field.org_col_name has broken value on secondary execution.
It happens when result field is created from the field which belongs to view
due to forgotten assignment of some Send_field attributes.
The fix:
set Send_field.org_col_name,org_table_name with correct value during Send_field intialization.
tests/mysql_client_test.c:
test case fix
The test was changed because now forgotten attributes are properly set.
Length value is the length of the field,
Max_length is the length of the field value.
So Max_length can not be more than Length.
The fix: fixed calculation of the Item_empty_string item length
(Patch applied and queued on demand of Trudy/Davi.)
sql/item.h:
fixed calculation of the item length
sql/sql_show.cc:
removed unnecessary code
When the fractional part in a multiplication of DECIMALs
overflowed, we truncated the first operand rather than the
longest. Now truncating least significant places instead
for more precise multiplications.
(Queuing at demand of Trudy/Davi.)
mysql-test/r/type_newdecimal.result:
show that if we need to truncate the scale of an operand, we pick the
right one (that is, we discard the least significant decimal places)
mysql-test/t/type_newdecimal.test:
show that if we need to truncate the scale of an operand, we pick the
right one (that is, we discard the least significant decimal places)
strings/decimal.c:
when needing to disregard fractional parts, pick the least
significant ones
with blobs containing nulls
Problem: FEDERATED SE improperly stores NULL fields in the record buffer.
Fix: store them properly.
mysql-test/r/federated.result:
Fix for bug #34779: crash in checksum table on federated tables
with blobs containing nulls
- test result.
mysql-test/t/federated.test:
Fix for bug #34779: crash in checksum table on federated tables
with blobs containing nulls
- test case.
sql/ha_federated.cc:
Fix for bug #34779: crash in checksum table on federated tables
with blobs containing nulls
- storing a NULL field in the record buffer
we must initialize its data as other code
may rely on it.
used causes server crash.
When the loose index scan access method is used values of aggregated functions
are precomputed by it. Aggregation of such functions shouldn't be performed
in this case and functions should be treated as normal ones.
The create_tmp_table function wasn't taking this into account and this led to
a crash if a query has MIN/MAX aggregate functions and employs temporary table
and loose index scan.
Now the JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate
functions as normal ones when the loose index scan is used.
mysql-test/r/group_min_max.result:
Added a test case for the bug#38195.
mysql-test/t/group_min_max.test:
Added a test case for the bug#38195.
sql/sql_select.cc:
Bug#38195: Incorrect handling of aggregate functions when loose index scan is
used causes server crash.
Now the JOIN::exec and the create_tmp_table functions treat MIN/MAX aggregate
functions as normal ones when the loose index scan is used.
Bug#35220: ALTER TABLE too picky on reserved word "foreign"
In ALTER TABLE, change the internal parser to search for
``FOREIGN[[:space:]]'' instead of only ``FOREIGN'' when parsing
ALTER TABLE ... DROP FOREIGN KEY ...; otherwise it could be mistaken
with ALTER TABLE ... DROP foreign_col;
(This fix is already present in MySQL 5.1 and higher.)
innodb-5.0-ss2475.
Bug #34286 Assertion failure in thread 2816 in file .\row\row0sel.c line 3500
Since autoinc init performs a MySQL SELECT query to determine the auto-inc
value, set prebuilt->sql_stat_start = TRUE so that it is performed like any
normal SELECT, regardless of the context in which it was invoked.
Bug #35352 If InnoDB crashes with UNDO slots full error the error persists on restart
We've added a heuristic that checks the size of the UNDO slots cache lists
(insert and upate). If either of cached lists has more than 500 entries then we
add any UNDO slots that are freed, to the common free list instead of the cache
list, this is to avoid the case where all the free slots end up in only one of
the lists on startup after a crash.
Tested with test case for 26590 and passes all mysql-test(s).
Bug #36600 SHOW STATUS takes a lot of CPU in buf_get_latched_pages_number
Fixed by removing the Innodb_buffer_pool_pages_latched variable from SHOW
STATUS output in non-UNIV_DEBUG compilation.
min() and max() functions are implemented in MySQL as macros.
This means that max(a,b) is expanded to: ((a) > (b) ? (a) : (b))
Note how 'a' is quoted two times.
Now imagine 'a' is a recursive function call that's several 10s of levels deep.
And the recursive function does max() with a function arg as well to dive into
recursion.
This means that simple function call can take most of the clock time.
Identified and fixed several such calls to max()/min() : including the IF()
sql function implementation.
mysql-test/r/func_if.result:
Bug#37662 test case
mysql-test/t/func_if.test:
Bug#37662 test case
sql/item.cc:
Bug#37662 don't call expensive functions as arguments to min/max
sql/item_cmpfunc.cc:
Bug#37662 don't call expensive functions as arguments to min/max
sql/item_func.cc:
Bug#37662 don't call expensive functions as arguments to min/max
Calling List<Cached_item>::delete_elements for the same list twice
caused a crash of the server in the function JOIN::cleaunup.
Ensured that delete_elements() in JOIN::cleanup would be called only once.
mysql-test/r/subselect.result:
Added a test case for bug #38191.
mysql-test/t/subselect.test:
Added a test case for bug #38191.
sql/sql_select.cc:
Fixed bug #38191.
Ensured that delete_elements() in JOIN::cleanup would be called only once.
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.
mysql-test/r/innodb_mysql.result:
Bug#37830 : test case
mysql-test/t/innodb_mysql.test:
Bug#37830 : test case
sql/opt_range.cc:
Bug#37830 :
- preserve and use used_key_parts to
distinguish when a primary key suffix is used
- removed some dead code
sql/opt_range.h:
Bug#37830 :
- preserve used_key_parts
- dead code removed
sql/sql_select.cc:
Bug#37830 : Do only reverse order traversal
if the primary key suffix is used.
- Revert the fix for bug 33812
- fixed a win32 warning
client/mysql.cc:
revert the fix for bug 33812
mysql-test/r/mysql.result:
revert the fix for bug 33812
mysql-test/t/mysql_delimiter.sql:
revert the fix for bug 33812
mysys/default.c:
fixed a win32 warning
build)
The crash was caused by freeing the internal parser stack during the parser
execution.
This occured only for complex stored procedures, after reallocating the parser
stack using my_yyoverflow(), with the following C call stack:
- MYSQLparse()
- any rule calling sp_head::restore_lex()
- lex_end()
- x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)
The root cause is the implementation of stored procedures, which breaks the
assumption from 4.1 that there is only one LEX structure per parser call.
The solution is to separate the LEX structure into:
- attributes that represent a statement (the current LEX structure),
- attributes that relate to the syntax parser itself (Yacc_state),
so that parsing multiple statements in stored programs can create multiple
LEX structures while not changing the unique Yacc_state.
Now, Yacc_state and the existing Lex_input_stream are aggregated into
Parser_state, a structure that represent the complete state of the (Lexical +
Syntax) parser.
mysql-test/r/parser_stack.result:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
mysql-test/t/parser_stack.test:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sp.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sp_head.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_class.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_class.h:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_lex.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_lex.h:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_parse.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_prepare.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_trigger.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_view.cc:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
sql/sql_yacc.yy:
Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on
build)
offset for time part in UUIDs was 1/1000 of what it
should be. In other words, offset was off.
Also handle the case where we count into the future
when several UUIDs are generated in one "tick", and
then the next call is late enough for us to unwind
some but not all of those borrowed ticks.
Lastly, handle the case where we keep borrowing and
borrowing until the tick-counter overflows by also
changing into a new "numberspace" by creating a new
random suffix.
mysql-test/r/func_misc.result:
Show that time-part of UUIDs is correct now.
mysql-test/t/func_misc.test:
Show that time-part of UUIDs is correct now
by replicating the C-code's resultin SQL.
Results also decode to expect date-data on
command-line (external validation).
No test for unwinding of borrowed ticks as
this a) is a race and b) depends on what timer
we get.
sql/item_strfunc.cc:
correct offset for date/time-part of UUID.
also make sure that when we counted into
the future earlier (several UUIDs generated
in same tick), we only give back as many
"borrowed" ticks as we can without duplicating
past timestamps. If our tick-counter overflows
before we can give back, or if the system-clock
is set back (by user or Daylight Saving Time),
we create a new random suffix to avoid
collisions and clear the tick-counter.
enabled)
Before this fix, the lexer and parser would treat the ';' character as a
different token (either ';' or END_OF_INPUT), based on convoluted logic,
which failed in simple cases where a stored procedure is implemented as a
single statement, and used in a multi query.
With this fix:
- the character ';' is always parsed as a ';' token in the lexer,
- parsing multi queries is implemented in the parser, in the 'query:' rules,
- the value of thd->client_capabilities, which is the capabilities
negotiated between the client and the server during bootstrap,
is immutable and not arbitrarily modified during parsing (which was the
root cause of the bug)
Bug#35658 (An empty binary value leads to mysqld crash)
Before this fix, the following token
b''
caused the parser to crash when reading the binary value from the empty string.
The crash was caused by:
ptr+= max_length - 1;
because max_length is unsigned and was 0, causing an overflow.
With this fix, an empty binary literal b'' is parsed as a binary value 0,
in Item_bin_string.
mysql-test/r/varbinary.result:
Bug#35658 (An empty binary value leads to mysqld crash)
mysql-test/t/varbinary.test:
Bug#35658 (An empty binary value leads to mysqld crash)
sql/item.cc:
Bug#35658 (An empty binary value leads to mysqld crash)
Bug#33812: mysql client incorrectly parsing DELIMITER
Remove unnecessary and incorrect code that tried
to pull delimiter commands out of the middle of
statements.
This bugs clarifies a warning message issued when the query cache data
size becomes smaller than the minium allowed size.
mysql-test/r/query_cache.result:
New warning message when a too small value has been set for query cache
size.
sql/set_var.cc:
To avoid poluting the QC API the warning messages are moved into the
QC module.
sql/share/errmsg.txt:
Changed error message so that minimal cache size always is hinted.
sql/sql_cache.cc:
Modified the warning message so that the minimal cache size always is
hinted.
Added interface method Query_cache::get_minimal_size_limit().
sql/sql_cache.h:
Modified the warning message so that the minimal cache size always is
hinted.
Added interface method Query_cache::get_minimal_size_limit().
mysql-test/r/federated_disabled.result:
Bug#37069 (5.0): test case
mysql-test/t/federated_disabled-master.opt:
Bug#37069 (5.0): test case
mysql-test/t/federated_disabled.test:
Bug#37069 (5.0): test case
Fix for this bug and additional improvements/fixes
In detail:
- Remove unicode attribute from several columns
(unicode properties were nowhere needed/tested)
of the table tb3
-> The runnability of these tests depends no more on
the availibility of some optional collations.
- Use a table tb3 with the same layout for all
engines to be tested and unify the engine name
within the protocols.
-> <engine>_trig_<abc>.result have the same content
- Do not load data into tb3 if these rows have no
impact on result sets
- Add tests for NDB (they exist already in 5.1)
- "--replace_result" at various places because
NDB variants of tests failed with "random" row
order in results
This fixes a till now unknown weakness within the
funcs_1 NDB tests existing in 5.1 and 6.0
- Fix the expected result of ndb_trig_1011ext
which suffered from Bug 32656
+ disable this test
- funcs_1 could be executed with the mysql-test-run.pl
option "--reorder", which saves some runtime by
optimizing server restarts.
Runtimes on tmpfs (one attempt only):
with reorder 132 seconds
without reorder 183 seconds
- Adjust two "check" statements within func_misc.test
which were incorrect (We had one run with result set
difference though the server worked good.)
- minor fixes in comments
Fix for this bug and a second similar problem
found during experimenting.
This replaces the first fix (already pushed to 5.1
and merged to 6.0) which
- failed in runs with the embedded server
- cannot be ported back to 5.0
first row or fails with an error:
ERROR 1022 (23000): Can't write; duplicate key in table ''
The server uses intermediate temporary table to store updated
row data. The first column of this table contains rowid.
Current server implementation doesn't reset NULL flag of that
column even if the server fills a column with rowid.
To keep each rowid unique, there is an unique index.
An insertion into an unique index takes into account NULL
flag of key value and ignores real data if NULL flag is set.
So, insertion of actually different rowids may lead to two
kind of problems. Visible effect of each of these problems
depends on an initial engine type of temporary table:
1. If multiupdate initially creates temporary table as
a MyISAM table (a table contains blob columns, and the
create_tmp_table function assumes, that this table is
large), it inserts only one single row and updates
only rows with one corresponding rowid. Other rows are
silently ignored.
2. If multiupdate initially creates MEMORY temporary
table, fills it with data and reaches size limit for
MEMORY tables (max_heap_table_size), multiupdate
converts MEMORY table into MyISAM table and fails
with an error:
ERROR 1022 (23000): Can't write; duplicate key in table ''
Multiupdate has been fixed to update the NULL flag of
temporary table rowid columns.
mysql-test/r/multi_update_tiny_hash.result:
Added test case for bug#36676.
mysql-test/t/multi_update_tiny_hash-master.opt:
Added test case for bug#36676.
mysql-test/t/multi_update_tiny_hash.test:
Added test case for bug#36676.
sql/sql_update.cc:
Fixed bug#36676: multiupdate using LEFT JOIN updates only
first row or fails with an error:
ERROR 1022 (23000): Can't write; duplicate key in table ''
The multi_update::send_data method has been modified to reset null bits of
fields containing rowids.
master also, so that we can visually see the slave is the same.
mysql-test/r/rpl_sp.result:
SHOW CREATE on master also.
mysql-test/t/rpl_sp.test:
SHOW CREATE on master also.
with dependent subqueries
An IN subquery is executed on EXPLAIN when it's not correlated.
If the subquery required a temporary table for its execution
not all the internal structures were restored from pointing to
the items of the temporary table to point back to the items of
the subquery.
Fixed by restoring the ref array when a temp tables were used in
executing the IN subquery during EXPLAIN EXTENDED.
mysql-test/r/subselect.result:
Bug #36011: test case
mysql-test/t/subselect.test:
Bug #36011: test case
sql/sql_select.cc:
Bug #36011: restore the ref array after execution
when there were temp tables.
mysql-test/r/rpl_sp.result:
Add binlog results to show that they're written correctly.
mysql-test/t/rpl_sp.test:
Add binlog results to show that they're written correctly.
slave
The stored-routine code took the contents of the (lowest) parser
and copied it directly to the binlog, which causes problems if there
is a special case of interpretation at the parser level -- which
there is, in the "/*!VER */" comments. The trailing "*/" caused
errors on the slave, naturally.
Now, since by that point we have /properly/ created parse-tree (as
the rest of the server should do!) for the stored-routine CREATE, we
can construct a perfect statement from that information, instead of
writing uncertain information from an unknown parser state.
Fortunately, there's already a function nearby that does exactly
that.
---
Update for Bug#36570. Qualify routine names with db name when
writing to the binlog ONLY if the source text is qualified.
mysql-test/r/binlog_innodb.result:
Offsets changed due to quoting.
---
New offset to account for db-qualified names.
mysql-test/r/ctype_cp932_binlog.result:
Offsets changed due to quoting.
---
Qualify routine names with DB. Offsets change also.
mysql-test/r/mysqlbinlog.result:
Case changed in result due to interpretation of data instead of
literal recitation.
---
Qualify procedure name with db.
mysql-test/r/rpl_sp.result:
Offsets changed due to quoting. Added tests.
---
Qualify routine names with DB if qualified in query. Offsets change also.
mysql-test/t/rpl_sp.test:
Add version-limiting quotes to exercise bug#36570. Test that
backtick-quoted identifiers and labels work also.
---
Use different db to show qualification works. Qualify routine names
with DB if qualified in query.
sql/sp.cc:
In create_string, we may not have a sp_name parameter yet, so
instead pass the char* and length of the only member we'd get out
of it.
Having done that, we can use the same function to write the
CREATE (FUNC|TRIG|PROC) statement to the binlog as we always used
to display the statement to the user.
---
Make the db name part of the CREATE string if it is specified.
Specify it in part of writing to the binlog when creating a new
routine.
sql/sp_head.cc:
Set the sp_head m_explicit_name member as the sp_name member is set.
We can not peek at this later, as the sp_name is gone by then.
sql/sp_head.h:
Add a member to track whether the name is qualified with the
database.
