Various parts of code used different 'precision' arguments for sprintf("%g") when converting
floating point numbers to a string. This led to differences in results in some cases
depending on whether the text-based or prepared statements protocol is used for a query.
Fixed by changing arguments to sprintf("%g") to always be 15 (DBL_DIG) so that results are
consistent regardless of the protocol.
This patch will be null-merged to 6.0 as the problem does not exists there (fixed by the
patch for WL#2934).
client/sql_string.cc:
Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
libmysql/libmysql.c:
Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
mysql-test/r/archive_gis.result:
Fixed test results to take additional precision into account.
mysql-test/r/func_group.result:
Fixed test results to take additional precision into account.
mysql-test/r/func_math.result:
Fixed test results to take additional precision into account.
mysql-test/r/func_str.result:
Fixed test results to take additional precision into account.
mysql-test/r/gis.result:
Fixed test results to take additional precision into account.
mysql-test/r/innodb_gis.result:
Fixed test results to take additional precision into account.
mysql-test/r/select.result:
Fixed test results to take additional precision into account.
mysql-test/r/sp.result:
Fixed test results to take additional precision into account.
mysql-test/r/type_float.result:
Fixed test results to take additional precision into account.
mysql-test/t/type_float.test:
Fixed test results to take additional precision into account.
sql/sql_string.cc:
Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
in trigger
Interchangeable calls to the mysql_change_user client function
and invocations of a trigger changing some user variable caused
a memory corruption and a crash.
The mysql_change_user API call forces TDH::cleanup() on a server
that frees user variable entries.
However it didn't reset Item_func_set_user_var::entry to NULL
because Item_func_set_user_var::cleanup() was not overloaded.
So, Item_func_set_user_var::entry held a pointer to freed memory,
that caused a crash.
The Item_func_set_user_var::cleanup method has been overloaded
to cleanup the Item_func_set_user_var::entry field.
mysql-test/r/user_var.result:
Added test case for bug #42188.
mysql-test/t/user_var.test:
Added test case for bug #42188.
sql/item_func.cc:
Bug#42188: crash and/or memory corruption with user variables
in trigger
The Item_func_set_user_var::cleanup method has been overloaded
to cleanup the Item_func_set_user_var::entry field.
sql/item_func.h:
Bug#42188: crash and/or memory corruption with user variables
in trigger
The Item_func_set_user_var::cleanup method has been overloaded
to cleanup the Item_func_set_user_var::entry field.
It's a regression issue.
The reason of the bug appeared to be an error introduced into 5.1 source code.
A piece of code in Create_file_log_event::do_apply_event() did not have test
coverage which made make test and pb unaware.
Fixed with inverting the old value of the return value from
Create_file_log_event::do_apply_event().
The rpl test suite is extended with `rpl_cross_version' the file to hold
regression cases similar to the current.
mysql-test/suite/rpl/r/rpl_cross_version.result:
new results file
mysql-test/suite/rpl/t/rpl_cross_version-master.opt:
options to the server to be able to start replication to itself
mysql-test/suite/rpl/t/rpl_cross_version.test:
regression test for bug#31240.
sql/log_event.cc:
Correcting the return value from Create_file_log_event::do_apply_event()
The problem is that the query cache was storing partial results
if the statement failed when sending the results to the client.
This could cause clients to hang when trying to read the results
from the cache as they would, for example, wait indefinitely for
a eof packet that wasn't saved.
The solution is to always discard the caching of a query that
failed to send its results to the associated client.
mysql-test/r/query_cache_notembedded.result:
Add test case result for Bug#40264
mysql-test/t/query_cache_notembedded.test:
Add test case for Bug#40264
sql/sql_cache.cc:
Abort if a unreported error was raised.
Views weren't sync()d the same way other structures were.
In creating the FRM for views, obey the same rules for variable
"sync_frm" as for everything else.
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
Problem:
1. trigger code didn't assume a table name may have
a "#mysql50#" prefix, that may lead to a failing ASSERT().
2. "ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME" failed
for databases with "#mysql50#" prefix if any trigger.
3. mysqlcheck --fix-table-name didn't use UTF8 as a default
character set that resulted in (parsing) errors for tables with
non-latin symbols in their names and definitions of triggers.
Fix:
1. properly handle table/database names with "#mysql50#" prefix.
2. handle --default-character-set mysqlcheck option;
if mysqlcheck is launched with --fix-table-name or --fix-db-name
set default character set to UTF8 if no --default-character-set
option given.
Note: if given --fix-table-name or --fix-db-name option,
without --default-character-set mysqlcheck option
default character set is UTF8.
client/mysqlcheck.c:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- check and set default charset if --default-character-set option
given.
- set default charset to "utf8" if there's
--fix-table-name or --fix-db-name and no --default-character-set.
mysql-test/r/mysqlcheck.result:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- test result.
mysql-test/t/mysqlcheck.test:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- test case.
sql/mysql_priv.h:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- check_n_cut_mysql50_prefix() introduced.
sql/sql_table.cc:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- tablename_to_filename() code split into 2 parts
- check_n_cut_mysql50_prefix() introduced to cut #mysql50# prefixes,
used in the trigger code as well.
sql/sql_trigger.cc:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- Table_triggers_list::check_n_load() - checking triggers assume
a table/database name given may have "#mysql50#" prefix in some cases.
- Table_triggers_list::change_table_name_in_triggers() -
create .TRG file in new database directory and delete it in old one,
as they may differ in case of
"ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME"
- Table_triggers_list::change_table_name_in_trignames() - remove stale .TRN
files in #mysql50#dbname directory in case of database upgrade
- Table_triggers_list::change_table_name() - allow changing trigger's
database in case of its upgrading
sql/sql_trigger.h:
Fix for
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.
- new old_db_name parameter added in
Table_triggers_list::change_table_name_in_trignames() and
Table_triggers_list::change_table_name_in_triggers()
The next number (AUTO_INCREMENT) field of the table for write
rows events are not initialized, and cause some engines (innodb)
not correctly update the tables's auto_increment value.
This patch fixed this problem by honor next number fields if present.
mysql-test/extra/rpl_tests/rpl_auto_increment.test:
Add test code for BUG#41986
mysql-test/suite/rpl/r/rpl_auto_increment.result:
update test result file for BUG#41986
sql/log_event.cc:
set next_number_field before writing rows, and reset next_number_field after finished writing rows
The problem is that the query cache stores packets containing
the server status of the time when the cached statement was run.
This might lead to a wrong transaction status in the client side
if a statement is cached during a transaction and is later served
outside a transaction context (and vice-versa).
The solution is to take into account the transaction status when
storing in and serving from the query cache.
mysql-test/r/innodb_cache.result:
Update test case result.
mysql-test/r/query_cache.result:
Add test case result for Bug#36326
mysql-test/t/query_cache.test:
Add test case for Bug#36326
sql/mysql_priv.h:
Add new flags.
sql/sql_cache.cc:
Remember the transaction and autocommit status stored in the packet.
tests/mysql_client_test.c:
Add test case for Bug#36326
The greedy optimizer tracks the current level of nested joins and the position
inside these by setting and maintaining a state that's global for the whole FROM
clause.
This state was correctly maintained inside the selection of the next partial plan
table (in best_extension_by_limited_search()).
greedy_search() also moves the current position by adding the last partial match
table when there's not enough tables in the partial plan found by
best_extension_by_limited_search().
This may require update of the global state variables that describe the current
position in the plan if the last table placed by greedy_search is not a top-level
join table.
Fixed by updating the state after placing the partial plan table in greedy_search()
in the same way this is done on entering the best_extension_by_limited_search().
Fixed the signature of the function called to update the state :
check_interleaving_with_nj
mysql-test/r/greedy_optimizer.result:
Bug #38795: test case
mysql-test/t/greedy_optimizer.test:
Bug #38795: test case
sql/sql_select.cc:
Bug #38795: correctly update current position when placing
the next partial plan table in greedy_search().
Bounds-checks and blocksize corrections were applied to user-input,
but constants in the server were trusted implicitly. If these values
did not actually meet the requirements, the user could not set change
a variable, then set it back to the (wonky) factory default or maximum
by explicitly specifying it (SET <var>=<value> vs SET <var>=DEFAULT).
Now checks also apply to the server's presets. Wonky values and maxima
get corrected at startup. Consequently all non-offsetted values the user
sees are valid, and users can set the variable to that exact value if
they so desire.
mysql-test/r/read_buffer_size_basic.result:
test sets out of bounds value; we now throw a warning for this.
This is a side-effect: before, the maximum was higher than the
value we set here. The value was corrected to block-size, the
maximum was not, hence the value was smaller than the maximum
in this particular case. Now that we align the maxima at startup,
the value in SET is larger than the (corrected) maximum, and we
see a warning in this particular case. "This means we're doing it right."
mysql-test/r/read_rnd_buffer_size_basic.result:
test sets out of bounds value; we now throw a warning for this.
This is a side-effect: before, the maximum was higher than the
value we set here. The value was corrected to block-size, the
maximum was not, hence the value was smaller than the maximum
in this particular case. Now that we align the maxima at startup,
the value in SET is larger than the (corrected) maximum, and we
see a warning in this particular case. "This means we're doing it right."
mysys/my_getopt.c:
Do bounds-checking at start-up time so we'll catch and correct
wonky default values and upper limits.
sql/mysqld.cc:
If 0 is a legal value per the docs, not to mention the default, we shouldn't give 1 as
the lower limit.
storage/innobase/handler/ha_innodb.cc:
We are setting upper bounds here.
~0L gives -1. That is NOT what we want!
post push fix, added test found a valgrind warning
sql/sql_partition.cc:
Bug#40972: Partition pruning can lead to crash for bad dates
Fix for valgrind warning
Adding comments to some of the high-level functions in replication.
sql/log_event.h:
Fixed some mistakes in comments.
sql/repl_failsafe.cc:
Added comment for show_slave_hosts()
sql/slave.cc:
Added comment for show_master_info(), handle_slave_[sql|io](), and next_event()
sql/sql_binlog.cc:
Added @param comment.
sql/sql_lex.h:
Added comment for st_lex_master_info.
sql/sql_repl.cc:
Added comments for functions executing a statement:
PURGE BINARY LOGS
START SLAVE
STOP SLAVE
RESET SLAVE
CHANGE MASTER
RESET MASTER
SHOW BINLOG EVENTS
SHOW MASTER STATUS
SHOW BINARY LOGS
No need to mask the error code returned by getting the next row to end of file when
doing filesort.
mysql-test/r/innodb_mysql_rbk.result:
Bug #41543: test case
mysql-test/t/innodb_mysql_rbk-master.opt:
Bug #41543: test case
mysql-test/t/innodb_mysql_rbk.test:
Bug #41543: test case
sql/filesort.cc:
Bug #41543: No need to mask the error code returned by getting the next row to end of file when
doing filesort.
When substituting system constant functions with a constant result
the server was not expecting that the function may return NULL.
Fixed by checking for NULL and returning Item_null (in the relevant
collation) if the result of the system constant function was NULL.
mysql-test/r/mysql.result:
Bug #41437: test case
mysql-test/t/mysql.test:
Bug #41437: test case.
Relies on database() returning NULL if no database is
selected.
sql/item_strfunc.cc:
Bug #41437: Check for NULL result on evaluating the system
constant function and return a constant NULL item.
The special TRUNCATE TABLE (DDL) transaction wasn't being properly
rolled back if a error occurred during row by row deletion. The
error can be caused by a foreign key restriction imposed by InnoDB
SE and would cause the server to erroneously issue a implicit
commit.
The solution is to rollback the transaction if a truncation via row
by row deletion fails, otherwise commit. All effects of a TRUNCATE
ABLE operation are rolled back if a row by row deletion fails.
mysql-test/include/commit.inc:
Truncate always starts a transaction and commits at the end.
The commit at the end increases the count by two, one is the
storage engine commit and the other is the binary log.
mysql-test/r/commit_1innodb.result:
Update test case results.
mysql-test/r/innodb_mysql.result:
Update test case results.
mysql-test/t/innodb_mysql.test:
Add test case for Bug#37016
sql/sql_delete.cc:
Move truncation using row by row deletion to its own function.
If row by row deletion fails, rollback the transaction.
Remove the meddling with disabling and enabling of autocommit
as TRUNCATE transaction is now explicitly ended (committed
or rolled back).
Problem: when the server reads a log_event from file, it should read
the post-header lengths from the format_description_log_event. Some
event types which currently have post-header length 0 did not do this,
and instead had a hard-coded zero length for the post-header. That
means the current server version will not be able to read future
versions of these events.
Fix: make the reader functions read the post-header.
sql/log_event.cc:
- Made Format_description_log_event constructor initialize all
post-header lengths explicitly, to make it easier to find them
in the source code.
- After this, it is no longer necessary to pass the MY_ZEROFILL
flag to my_malloc. I removed the flag and added a sanity-check
that will be executed only in debug-mode.
- Made INTVAR, RAND, USER_VAR, and XID events skip post_header_len
when reading from file.
sql/log_event.h:
Added explicit defines for the lengths of all event types.
The binlog_innodb test was sensitive to what tests ran before it. Now run
FLUSH STATUS before performing operations that need to be checked.
sys_var_thd_ulong::update() was improperly casting an option value from
ulonglong to ulong before comparing it to the max allowed value. On systems
where ulong and ulonglong are of different size, this caused values greater
than ULONG_MAX to wrap around (not be truncated to ULONG_MAX, which appears to
have been the intention of the original coder), and caused some checks to work
incorrectly. This wasn't generally visible to the user, because later checks
would prevent the wrapped-around value from being used. But it caused warning
messages to differ between 32- and 64-bit platforms. Fix is to just remove the
cast. Also added a DBUG_ASSERT to ensure that the value really is capped
properly before finally stuffing it into the ulong.
locking type of temp table
The problem is that INSERT INTO .. SELECT FROM .. and CREATE
TABLE .. SELECT FROM a temporary table could inadvertently
overwrite the locking type of the temporary table. The lock
type of temporary tables should be a write lock by default.
The solution is to reset the lock type of temporary tables
back to its default value after they are used in a statement.
mysql-test/r/innodb_mysql.result:
Add test case result for Bug#41348
mysql-test/r/temp_table.result:
Add test case result for Bug#41348
mysql-test/t/innodb_mysql.test:
Add test case for Bug#41348
mysql-test/t/temp_table.test:
Add test case for Bug#41348
sql/sql_base.cc:
Allow the lock type of temp tables to be overwritten now that
the the value is being restored once the table is marked as
free for re-use. This makes the behavior consistent with that
of non-temporary tables and avoids confusion.
Execution of queries containing the CASE function of
aggregate function like in "SELECT ... CASE ARGV(...) WHEN ..."
crashed the server.
The CASE function caches pointers to concrete comparison
functions for an each pair of types of CASE-WHERE clause
parameters, i.e. for the "CASE INT_RESULT WHERE REAL_RESULT
THEN ... WHERE DECIMAL_RESULT ... END" function call it
caches comparisons for INT_RESULT with REAL_RESULT and
for INT_RESULT with DECIMAL_RESULT. Usually a result
type is known after a call to the fix_fields function,
however, the setup_copy_fields function call may
wrap aggregate items with Item_copy_string that has
STRING_RESULT result type, so setup_copy_fields may
change argument result types of the CASE function after
call to Item_func_case::fix_fields/fix_length_and_dec.
Then the Item_func_case::find_item function tries to
use comparison function for unexpected pair of the
STRING_RESULT and some other type - that caused
an assertion failure of server crash.
The Item_func_case::fix_length_and_dec function has
been modified to take into account possible STRING_RESULT
result type in the presence of aggregate arguments of
the CASE function.
mysql-test/r/func_in.result:
Added test case for bug #41363.
mysql-test/t/func_in.test:
Added test case for bug #41363.
sql/item_cmpfunc.cc:
Bug #41363: crash of mysqld on windows with aggregate in case
The Item_func_case::fix_length_and_dec function has
been modified to take into account possible STRING_RESULT
result type in the presence of aggregate arguments of
the CASE function.
