Item_func_spatial_collection::val_str
When the concatenation function for geometry data collections
reads the binary data it was not rigorous in checking that there
is data available, leading to invalid reads and crashes.
Fixed by making checking stricter.
mysql-test/r/gis.result:
Bug#44684: Test result
mysql-test/t/gis.test:
Bug#44684: Test case
sql/item_geofunc.cc:
Bug#44684: fix(es)
- Check that there are 4 bytes available for type code.
- Check that there is at least one point available for linestring.
- Check that there are at least 2 points in a polygon and
data for all the points.
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
The assertion in String::copy was added in order to avoid
valgrind errors when the destination was the same as the source.
Eased restriction to allow for the case when str == NULL.
mysql-test/r/func_set.result:
Bug#45168: Test result
mysql-test/t/func_set.test:
Bug#45168: Test case
sql/item_strfunc.cc:
Bug#45168: Code cleanup and grammar correction in comment
sql/sql_string.cc:
Bug#45168: Fix
Early patch submitted for discussion.
It is possible for more than one thread to enter the condition
in query_cache_insert(), but the condition predicate is to
signal one thread each time the cache status changes between
the following states: {NO_FLUSH_IN_PROGRESS,FLUSH_IN_PROGRESS,
TABLE_FLUSH_IN_PROGRESS}
Consider three threads THD1, THD2, THD3
THD2: select ... => Got a writer in ::store_query
THD3: select ... => Got a writer in ::store_query
THD1: flush tables => qc status= FLUSH_IN_PROGRESS;
new writers are blocked.
THD2: select ... => Still got a writer and enters cond in
query_cache_insert
THD3: select ... => Still got a writer and enters cond in
query_cache_insert
THD1: flush tables => finished and signal status change.
THD2: select ... => Wakes up and completes the insert.
THD3: select ... => Happily waiting for better times. Why hurry?
This patch is a refactoring of this lock system. It introduces four new methods:
Query_cache::try_lock()
Query_cache::lock()
Query_cache::lock_and_suspend()
Query_cache::unlock()
This change also deprecates wait_while_table_flush_is_in_progress(). All threads are
queued and put on a conditional wait. On each unlock the queue is signalled. This resolve
the issues with left over threads. To assure that no threads are spending unnecessary
time waiting a signal broadcast is issued every time a lock is taken before a full
cache flush.
mysql-test/r/query_cache_debug.result:
* Added test case for bug43758
mysql-test/t/query_cache_debug.test:
* Added test case for bug43758
sql/sql_cache.cc:
* Replaced calls to wait_while_table_flush_is_in_progress() with
calls to try_lock(), lock_and_suspend() and unlock().
* Renamed enumeration Cache_status to Cache_lock_status.
* Renamed enumeration items to UNLOCKED, LOCKED_NO_WAIT and LOCKED.
If the LOCKED_NO_WAIT lock type is used to lock the query cache, other
threads using try_lock() will fail to acquire the lock.
This is useful if the query cache is temporary disabled due to
a full table flush.
sql/sql_cache.h:
* Replaced calls to wait_while_table_flush_is_in_progress() with
calls to try_lock(), lock_and_suspend() and unlock().
* Renamed enumeration Cache_status to Cache_lock_status.
* Renamed enumeration items to UNLOCKED, LOCKED_NO_WAIT and LOCKED.
If the LOCKED_NO_WAIT lock type is used to lock the query cache, other
threads using try_lock() will fail to acquire the lock.
This is useful if the query cache is temporary disabled due to
a full table flush.
crashes server!
The problem affects the scenario when index merge is followed by a filesort
and the sort buffer is not big enough for all the sort keys.
In this case the filesort function will read the data to the end through the
index merge quick access method (and thus closing the cursor etc),
but will leave the pointer to the quick select method in place.
It will then create a temporary file to hold the results of the filesort and
will add it as a sort output file (in sort.io_cache).
Note that filesort will copy the original 'sort' structure in an automatic
variable and restore it after it's done.
As a result at exiting filesort() we have a sort.io_cache filled in and
nothing else (as a result of close of the cursors at end of reading data
through index merge).
Now create_sort_index() will note that there is a select and will clean it up
(as it's been used already by filesort() reading the data in). While doing that
a special case in the index merge destructor will clean up the sort.io_cache,
assuming it's an output of the index merge method and is not needed anymore.
As a result the code that tries to read the data back from the filesort output
will get no data in both memory and disk and will crash.
Fixed similarly to how filesort() does it : by copying the sort.io_cache structure
to a local variable, removing the pointer to the io_cache (so that it's not freed
by QUICK_INDEX_MERGE_SELECT::~QUICK_INDEX_MERGE_SELECT) and restoring the original
structure (together with the valid pointer) after the cleanup is done.
This is a safe thing to do because all the structures are already cleaned up by
hitting the end of the index merge's read method (QUICK_INDEX_MERGE_SELECT::get_next())
and the cleanup code being written in a way that tolerates repeating cleanups.
mysql-test/r/index_merge.result:
Bug #44810: test case
mysql-test/t/index_merge.test:
Bug #44810: test case
sql/sql_select.cc:
Bug #44810: preserve the io_cache produced by filesort while cleaning up
the index merge quick access method (QUICK_INDEX_MERGE_SELECT).
The SQL-mode PAD_CHAR_TO_FULL_LENGTH could prevent a DROP USER
statement from privileges associated with the user being dropped.
What ocurred was that reading from the User and Host fields of
the tables tables_priv or columns_priv would yield values padded
with spaces, causing a failure to match a specified user or host
('user' != 'user ');
The solution is to disregard the PAD_CHAR_TO_FULL_LENGTH mode
when iterating over and matching values in the privileges tables
for a DROP USER statement.
mysql-test/r/sql_mode.result:
Add test case result for Bug#45100.
mysql-test/t/sql_mode.test:
Add test case for Bug#45100.
sql/sql_acl.cc:
Clear MODE_PAD_CHAR_TO_FULL_LENGTH before dropping privileges.
statements missed from general log
A refinement of the test in the previous patch to avoid
using sleep as a means to ensure that timestamps are
added to the log entries.
mysql-test/t/log_tables_debug.test:
New test file. A debug feature is used to ensure that
log entries are prefixed with a timestamp.
sql/log.cc:
A debug feature is implemented to ensure that
log entries are prefixed with a timestamp.
WHERE and GROUP BY clause
Loose index scan may use range conditions on the argument of
the MIN/MAX aggregate functions to find the beginning/end of
the interval that satisfies the range conditions in a single go.
These range conditions may have open or closed minimum/maximum
values. When the comparison returns 0 (equal) the code should
check the type of the min/max values of the current interval
and accept or reject the row based on whether the limit is
open or not.
There was a wrong composite condition on checking this and it was
not working in all cases.
Fixed by simplifying the conditions and reversing the logic.
mysql-test/r/group_min_max.result:
Bug #45386: test case
mysql-test/t/group_min_max.test:
Bug #45386: test case
sql/opt_range.cc:
Bug #45386: fix the check whether to use the value if on the
interval boundry
While reading a binary log that is being used by a master or was not properly
closed, most likely due to a crash, the following warning message is being
printed out: "Warning: this binlog was not closed properly. Most probably mysqld
crashed writing it.". This was scaring our users as the message was not taking
into account the possibility of the file is being just used by the master.
To avoid unnecessarily scaring our users, we replace the original message by the
following one: Warning: "this binlog is either is use or was not closed properly.".
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
Range analysis did not request sorted output from the storage engine,
which cause partitioned handlers to process one partition at a time
while reading key prefixes in ascending order, causing values to be
missed. Fixed by always requesting sorted order during range analysis.
This fix is introduced in 6.0 by the fix for bug no 41136.
mysql-test/r/group_min_max.result:
Bug#44821: Test result.
mysql-test/t/group_min_max.test:
Bug#44821: Test case
sql/opt_range.cc:
Bug#44821: Fix.
Remove custom DLL loader code from innodb plugin code, use
symbols exported from mysqld.
storage/innodb_plugin/handler/ha_innodb.cc:
Remove a Win32 workaround for current_thd.
The original problem that innodb plugin used
value of TLS variable across DLL boundaries is
solved in MySQL server (current_thd is a function
not TLS variable now)
storage/innodb_plugin/handler/handler0alter.cc:
Remove custom delay loader
storage/innodb_plugin/handler/handler0vars.h:
Remove custom delay loader
storage/innodb_plugin/handler/i_s.cc:
Remove custom delay loader
storage/innodb_plugin/handler/win_delay_loader.cc:
Remove custom delay loader
storage/innodb_plugin/plug.in:
Remove commented out MYSQL_PLUGIN_STATIC,
CMake would not parse that correctly
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number
of the warnings, predominantly "suggest using parentheses
around && in ||", and empty for and while bodies.
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number
of the warnings, predominantly "suggest using parentheses
around && in ||", and empty for and while bodies.
variable. The problem was that THD::connect_utime could be
used without being initialized when the main thread is used
to handle connections (--thread-handling=no-threads).
sql/mysqld.cc:
Set THD::start_utime even in no-threads handling mode.
sql/sql_class.cc:
Initialize variable.
sql/sql_class.h:
Rename connect_utime to prior_thr_create_utime as to
better reflect it's use intention.
sql/sql_connect.cc:
Check only if a thread was actually created.
mysqlbinlog --database parameter was being ignored when processing
row events. As such no event filtering would take place.
This patch addresses this by deploying a call to shall_skip_database
when table_map_events are handled (as these contain also the name of
the database). All other rows events referencing the table id for the
filtered map event, will also be skipped.
client/mysqlbinlog.cc:
Added shall_skip_database call to the part of the code that handles
Table_map_log_events. It inspects the database name and decides whether
to filter the event or not. Furthermore, if table map event is filtered
next events referencing the table id in the table map event, will also
be filtered.
mysql-test/suite/binlog/t/binlog_row_mysqlbinlog_db_filter.test:
Test case that checks if row events are actually filtered out.
sql/log_event.h:
Added a map for holding the currently ignored table map events.
Table map events are inserted when they shall be skipped and removed
once the last row event in the statement is processed.
uninitialized variable used as subscript
Grouping select from a "constant" InnoDB table (a table
of a single row) joined with other tables caused a crash.
mysql-test/r/innodb_mysql.result:
Added test case for bug bug #44886.
mysql-test/t/innodb_mysql.test:
Added test case for bug bug #44886.
sql/sql_select.cc:
Bug #44886: SIGSEGV in test_if_skip_sort_order() -
uninitialized variable used as subscript
1. The test_if_order_by_key function returned unitialized
used_key_parts parameter in case of a "constant" InnoDB
table. Calling function uses this parameter values as
an array index, thus sometimes it caused a crash.
The test_if_order_by_key function has been modified
to set used_key_parts to 0 (no need for ordering).
2. The test_if_skip_sort_order function has been
modified to accept zero used_key_parts value and
to prevent an array access by negative index.
The problem is that when a optimization of read-only transactions
(bypass 2-phase commit) was implemented, it removed the code that
reseted the XID once a transaction wasn't active anymore:
sql/sql_parse.cc:
- bzero(&thd->transaction.stmt, sizeof(thd->transaction.stmt));
- if (!thd->active_transaction())
- thd->transaction.xid_state.xid.null();
+ thd->transaction.stmt.reset();
This mostly worked fine as the transaction commit and rollback
functions (in handler.cc) reset the XID once the transaction is
ended. But those functions wouldn't reset the XID in case of
a empty transaction, leading to a assertion when a new starting
a new XA transaction.
The solution is to ensure that the XID state is reset when empty
transactions are ended (by either commit or rollback). This is
achieved by reorganizing the code so that the transaction cleanup
routine is invoked whenever a transaction is ended.
mysql-test/r/xa.result:
Add test case result for Bug#44672
mysql-test/t/xa.test:
Add test case for Bug#44672
sql/handler.cc:
Invoke transaction cleanup function whenever a transaction is
ended. Move XID state reset logic to the transaction cleanup
function.
sql/sql_class.h:
Add XID state reset logic.
Holding on to the temporary inno hash index latch is an optimization in
many cases, but a pessimization in some others.
Release temporary latches for those corner cases we (or rather, or customers,
thanks!) have identified, that is, when we are about to do something that
might take a really long time, like REPAIR or filesort.
sql/ha_myisam.cc:
Let go of (inno, for now) latch when doing MyISAM-repair.
(optimize passes through repair.) ("Stuck" in "Repair with
keycache".)
sql/sql_insert.cc:
Let go of (inno, for now) latch when doing CREATE...SELECT
in select_insert::send_data() -- it might take a while.
("stuck" in "Sending data")
sql/sql_select.cc:
Release temporary (inno, for now) latch on
- free_tmp_table() (this can take surprisingly long, "removing tmp table")
- create_myisam_from_heap() (HEAP table overflowing onto disk as MyISAM,
"converting HEAP to MyISAM")
When copying the Item class one must copy its attributes as well.
mysql-test/r/innodb_mysql.result:
Bug #36995: test case
mysql-test/t/innodb_mysql.test:
Bug #36995: test case
sql/item.cc:
Bug #36995: copy attributes in the copy constructor
The crash happens because of uninitialized
lex->ssl_cipher, lex->x509_subject, lex->x509_issuer variables.
The fix is to add initialization of these variables for
stored procedures&functions.
mysql-test/r/sp_notembedded.result:
test result
mysql-test/t/sp_notembedded.test:
test case
sql/sql_acl.cc:
The crash happens because of uninitialized
lex->ssl_cipher, lex->x509_subject, lex->x509_issuer variables.
The fix is to add initialization of these variables for
stored procedures&functions.
The server was not cleaning the last IO error and error number when
resetting slave.
This patch addresses this issue by backporting into 5.1 part of the
patch in BUG 34654. A fix for this issue had already been pushed into
6.0 as part of the aforementioned bug, however the patch also included
some refactoring. The fix for 5.1 does not take into account the
refactoring part.
mysql-test/extra/rpl_tests/rpl_reset_slave.test:
Backported the test case and improved with deploying include/start_slave.inc
in relevant spots.
sql/slave.cc:
Backported part of patch from 6.0 that includes cleaning
mi->clear_error() at:
1. beginning of handle_slave_io
2. on successful connection
Also, backported the assertion added in the original patch.
sql/sql_repl.cc:
Backported the call to mi->clear_error() on reset_slave().
always rollsback.
There is failure on pushbuild machines which are using old compilers complaining about
ULLONG_MAX declaration. Changing this to ULONGLONG_MAX to solve the problem.
sql/mysqld.cc:
Change ULLONG_MAX to ULONGLONG_MAX for the max_binlog_cache_size option
or database name in logs
Problem was that InnoDB used filenam_to_tablename,
which do not handle partitions (due to the '#' in
the filename).
Solution is to add a new function for explaining
what the filename means: explain_filename.
It expands the database, table, partition and subpartition
parts and uses errmsg.txt for localization.
It also converts from my_charset_filename to system_charset_info
(i.e. human readable form for non ascii characters).
http://lists.mysql.com/commits/70370
2773 Mattias Jonsson 2009-03-25
It has three different output styles.
NOTE: This is the server side ONLY part (introducing the explain_filename
function). There will be a patch for InnoDB using this function to solve
the bug.
sql/mysql_priv.h:
Bug#32430:'show innodb status' causes errors Invalid (old?) table
or database name in logs
Added EXPLAIN_FILENAME_MAX_EXTRA_LENGTH, enum_explain_filename_mode
and explain_filename.
sql/share/errmsg.txt:
Bug#32430:'show innodb status' causes errors Invalid (old?) table
or database name in logs
Added localization names for Database, Table, Partition, Subpartition
Temporary and Renamed.
sql/sql_table.cc:
Bug#32430:'show innodb status' causes errors Invalid (old?) table
or database name in logs
Added explain_filename function for giving better information
to the user about a specific table/partitions file.
The crash happens due to wrong max_length value which is set on
Item_func_round::fix_length_and_dec() stage. The value is set to
args[0]->max_length which is too big in case of LONGTEXT(LONGBLOB) fields.
The fix is to set max_length using float_length() function.
mysql-test/r/func_math.result:
test result
mysql-test/t/func_math.test:
test case
sql/item_func.cc:
The crash happens due to wrong max_length value which is set on
Item_func_round::fix_length_and_dec() stage. The value is set to
args[0]->max_length which is too big in case of LONGTEXT(LONGBLOB) fields.
The fix is to set max_length using float_length() function.
BEGIN/COMMIT/ROLLBACK was subject to replication db rules, and
caused the boundary of a transaction not recognized correctly
when these queries were ignored by the rules.
Fixed the problem by skipping replication db rules for these
statements.
sql/log_event.cc:
Skip checking replication db rules for BEGIN/COMMIT/ROLLBACK statements
Make the caller of Query_log_event, Execute_load_log_event
constructors and THD::binlog_query to provide the error code
instead of having the constructors to figure out the error code.
sql/log_event.cc:
Changed constructors of Query_log_event and Execute_load_log_event to accept the error code argument instead of figuring it out by itself
sql/log_event.h:
Changed constructors of Query_log_event and Execute_load_log_event to accept the error code argument
When doing ALTER TABLE, we forgot to point out that we actually have
ROW_FORMAT information (from the original table), so we dropped to
"sensible defaults". This affects both ALTER TABLE and OPTIMIZE TABLE
which may fall back on ALTER TABLE for InnoDB.
We now flag that we do indeed know the row-type, thereby preserving
compression-type etc.
No .test in 5.1 since we'd need a reasonable new plugin from InnoDB to
show this properly; in higher versions, maria can demonstrate this.
sql/sql_table.cc:
In mysql_alter_table() flag that we have row-type info
from old table. In compare_tables(), we must explicitly
check whether row-type has changed (rather than rely on
the flag which will always be set at this point now).
MySQL crashes if a user without proper privileges attempts to create a procedure.
The crash happens because more than one error state is pushed onto the Diagnostic
area. In this particular case the user is denied to implicitly create a new user
account with the implicitly granted privileges ALTER- and EXECUTE ROUTINE.
The new account is needed if the original user account contained a host mask.
A user account with a host mask is a distinct user account in this context.
An alternative would be to first get the most permissive user account which
include the current user connection and then assign privileges to that
account. This behavior change is considered out of scope for this bug patch.
The implicit assignment of privileges when a user creates a stored routine is a
considered to be a feature for user convenience and as such it is not
a critical operation. Any failure to complete this operation is thus considered
non-fatal (an error becomes a warning).
The patch back ports a stack implementation of the internal error handler interface.
This enables the use of multiple error handlers so that it is possible to intercept
and cancel errors thrown by lower layers. This is needed as a error handler already
is used in the call stack emitting the errors which needs to be converted.
mysql-test/r/grant.result:
* Added test case for bug44658
mysql-test/t/grant.test:
* Added test case for bug44658
sql/sp.cc:
* Removed non functional parameter no_error and my_error calls as all errors
from this function will be converted to a warning anyway.
* Change function return type from int to bool.
sql/sp.h:
* Removed non functional parameter no_error and my_error calls as all errors
from this function will be converted to a warning anyway.
* Changed function return value from int to bool
sql/sql_acl.cc:
* Removed the non functional no_error parameter from the function prototype.
The function is called from two places and in one of the places we now
ignore errors through error handlers.
* Introduced the parameter write_to_binlog
* Introduced an error handler to cancel any error state from mysql_routine_grant.
* Moved my_ok() signal from mysql_routine_grant to make it easier to avoid
setting the wrong state in the Diagnostic area.
* Changed the broken error state in sp_grant_privileges() to a warning
so that if "CREATE PROCEDURE" fails because "Password hash isn't a hexidecimal
number" it is still clear what happened.
sql/sql_acl.h:
* Removed the non functional no_error parameter from the function prototype.
The function is called from two places and in one of the places we now
ignore errors through error handlers.
* Introduced the parameter write_to_binlog
* Changed return type for sp_grant_privileges() from int to bool
sql/sql_class.cc:
* Back ported implementation of internal error handler from 6.0 branch
sql/sql_class.h:
* Back ported implementation of internal error handler from 6.0 branch
sql/sql_parse.cc:
* Moved my_ok() signal from mysql_routine_grant() to make it easier to avoid
setting the wrong state in the Diagnostic area.
Added a more detailed error message on calling an ambiguous missing function.
mysql-test/r/ps.result:
Bug #38159: fixed existing tests
mysql-test/r/sp-error.result:
Bug #38159: test case
mysql-test/t/ps.test:
Bug #38159: fixed existing tests
mysql-test/t/sp-error.test:
Bug #38159: test case
sql/item_func.cc:
Bug #38159: generate more detailed error message
sql/share/errmsg.txt:
Bug #38159: add a more detailed error message
sql/sql_derived.cc:
Bug #38159: treat the detailed error message the same way as the
generic one
sql/sql_lex.cc:
Bug #38159:
- detect if the token is ambiguous and print the appropriate error.
- backport is_lex_native_function() from 5.1
sql/sql_lex.h:
Bug #38159: detect if the token is ambiguous and print the appropriate error.
sql/sql_yacc.yy:
Bug #38159: generate more detailed error message
sql/table.cc:
Bug #38159: treat the detailed error message the same way as the
generic one
On 64-bit Windows: querying MERGE table with keys may cause
server crash.The problem is generic and may affect any statement
accessing MERGE table cardinality values.
When MERGE engine was copying cardinality statistics, it was
using incorrect size of element in cardinality statistics array
(sizeof(ptr)==8 instead of sizeof(ulong)==4), causing access
of memory beyond of the allocated bounds.
sql/ha_myisam.cc:
When copying rec_per_key array (an array of ulong) use proper
size of element, that is sizeof(ulong).
sql/ha_myisammrg.cc:
When copying rec_per_key array (an array of ulong) use proper
size of element, that is sizeof(ulong).
sql/table.cc:
When allocating rec_per_key array (an array of ulong) use proper
size of element, that is sizeof(ulong).
old_password() functions
The PASSWORD() and OLD_PASSWORD() functions could lead to
memory reads outside of an internal buffer when used with BLOB
arguments.
String::c_ptr() assumes there is at least one extra byte
in the internally allocated buffer when adding the trailing
'\0'. This, however, may not be the case when a String object
was initialized with externally allocated buffer.
The bug was fixed by adding an additional "length" argument to
make_scrambled_password_323() and make_scrambled_password() in
order to avoid String::c_ptr() calls for
PASSWORD()/OLD_PASSWORD().
However, since the make_scrambled_password[_323] functions are
a part of the client library ABI, the functions with the new
interfaces were implemented with the 'my_' prefix in their
names, with the old functions changed to be wrappers around
the new ones to maintain interface compatibility.
mysql-test/r/func_crypt.result:
Added a test case for bug #44767.
mysql-test/t/func_crypt.test:
Added a test case for bug #44767.
sql/item_strfunc.cc:
Use the new my_make_scrambled_password*() to avoid
String::c_ptr().
sql/item_strfunc.h:
Changed Item_func[_old]_password::alloc() interfaces so that
we can use the new my_make_scrambled_password*() functions.
sql/mysql_priv.h:
Added declarations for the new my_make_scrambled_password*()
functions.
sql/password.c:
Added new my_make_scrambled_password*() functions with an
additional "length" argument. Changed ones to be wrappers
around the new ones to maintain interface compatibility.
sql/sql_yacc.yy:
Utilize the new password hashing functions with additional length
argument.
The problem is that the server failed to follow the rule that
every X509 object retrieved using SSL_get_peer_certificate()
must be explicitly freed by X509_free(). This caused a memory
leak for builds linked against OpenSSL where the X509 object
is reference counted -- improper counting will prevent the
object from being destroyed once the session containing the
peer certificate is freed.
The solution is to explicitly free every X509 object used.
mysql-test/r/openssl_1.result:
Add test case result for Bug#42158
mysql-test/t/openssl_1.test:
Add test case for Bug#42158
sql/sql_acl.cc:
Deallocate X509 objects.
HAVING
When calculating GROUP BY the server caches some expressions. It does
that by allocating a string slot (Item_copy_string) and assigning the
value of the expression to it. This effectively means that the result
type of the expression can be changed from whatever it was to a string.
As this substitution takes place after the compile-time result type
calculation for IN but before the run-time type calculations,
it causes the type calculations in the IN function done at run time
to get unexpected results different from what was prepared at compile time.
In the CASE ... WHEN ... THEN ... statement there was a similar problem
and it was solved by artificially adding a STRING argument to the set of
types of the IN/CASE arguments at compile time, so if any of the
arguments of the CASE function changes its type to a string it will
still be covered by the information prepared at compile time.
mysql-test/include/mix1.inc:
Bug #44399: extended the test to cover the different types
mysql-test/r/func_in.result:
Bug #44399: test case
mysql-test/r/innodb_mysql.result:
Bug #44399: extended the test to cover the different types
mysql-test/t/func_in.test:
Bug #44399: test case
sql/item.cc:
Bug #44399: Implement typed caching for GROUP BY
sql/item.h:
Bug #44399: Implement typed caching for GROUP BY
sql/item_cmpfunc.cc:
Bug #44399: remove the special case
sql/sql_select.cc:
Bug #44399: Implement typed caching for GROUP BY
stop/start slave
When stopping and restarting the slave while it is replicating
temporary tables, the server would crash or raise an assertion
failure. This was due to the fact that although temporary tables are
saved between slave threads restart, the reference to the thread in
use (table->in_use) was not being properly updated when the restart
happened (it would still reference the old/invalid thread instead of
the new one).
This patch addresses this issue by resetting the reference to the new
slave thread on slave thread restart.
mysql-test/r/rpl_temporary.result:
Result file.
mysql-test/t/rpl_temporary.test:
Test case that checks that both failures go away.
sql/slave.cc:
Changed slave.cc to reset sql_thd reference in temporary tables.
assertion .\filesort.cc, line 797
A query with the "ORDER BY @@some_system_variable" clause,
where @@some_system_variable is NULL, causes assertion
failure in the filesort procedures.
The reason of the failure is in the value of
Item_func_get_system_var::maybe_null: it was unconditionally
set to false even if the value of a variable was NULL.
mysql-test/r/variables.result:
Added test case for bug #42778.
mysql-test/suite/sys_vars/r/innodb_data_home_dir_basic.result:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/r/innodb_flush_method_basic.result:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/r/rpl_init_slave_func.result:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/r/ssl_capath_basic.result:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/r/ssl_cipher_basic.result:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/t/innodb_data_home_dir_basic.test:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/t/innodb_flush_method_basic.test:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/t/ssl_capath_basic.test:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/suite/sys_vars/t/ssl_cipher_basic.test:
Updated test case for bug #42778:
system variables were NOT NULL, now they are nullable.
mysql-test/t/variables.test:
Added test case for bug #42778.
sql/item.cc:
Bug #42778: delete order by null global variable causes
assertion .\filesort.cc, line 797
The longlong_from_string_with_check function has been modified
to skip unwanted warnings: now it uses the THD::no_errors
flag to suppress warnings.
The Item_func_get_system_var::update_null_value method
sets the no_error flag.
sql/item_func.cc:
Bug #42778: delete order by null global variable causes
assertion .\filesort.cc, line 797
1. The Item_func_get_system_var::fix_length_and_dec method
has been modified to make system variables truly nullable.
2. The Item_func_get_system_var::update_null_value method
method has been overloaded with a simple wrapper (like
Item_field::update_null_value) to suppress unwanted warnings
from Item_func_get_system_var::val_int() calls on non-numeric
variable values: the Item_func_get_system_var::update_null_value
method sets and restores THD::no_errors flag for a nested
call of the longlong_from_string_with_check function.
sql/item_func.h:
Bug #42778: delete order by null global variable causes
assertion .\filesort.cc, line 797
The Item_func_get_system_var::update_null_value method
method has been overloaded.
bug#44766: valgrind error when using convert() in a subquery
Problem: input and output buffers may be the same
converting a string to some charset.
That may lead to wrong results/valgrind warnings.
Fix: use different buffers.
mysql-test/r/cast.result:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- test result.
mysql-test/r/func_concat.result:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- test result.
mysql-test/t/cast.test:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- test case.
mysql-test/t/func_concat.test:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- test case.
sql/item.cc:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- comment added.
sql/item_strfunc.cc:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- '&args[0]->str_value' used as a parameter of args[0]->val_str(),
as 'str' may be equal to 'str_value' which we use as the output buffer
converting strings.
sql/sql_string.cc:
Fix for bug#44743: Join in combination with concat does not always work
bug#44766: valgrind error when using convert() in a subquery
- input and output buffers must NOT be the same.
warnings after uncompressed_length
UNCOMPRESSED_LENGTH() did not validate its argument. In
particular, if the argument length was less than 4 bytes,
an uninitialized memory value was returned as a result.
Since the result of COMPRESS() is either an empty string or
a 4-byte length prefix followed by compressed data, the bug was
fixed by ensuring that the argument of UNCOMPRESSED_LENGTH() is
either an empty string or contains at least 5 bytes (as done in
UNCOMPRESS()). This is the best we can do to validate input
without decompressing.
mysql-test/r/func_compress.result:
Added a test case for bug #44796.
mysql-test/t/func_compress.test:
Added a test case for bug #44796.
sql/item_strfunc.cc:
Make sure that the argument of UNCOMPRESSED_LENGTH() contains
at least 5 bytes (as done in UNCOMPRESS()).
Change the warning message to 'Statement may not be safe to log in
statement format' to indicate that the decision on whether a
statement is safe or not is heuristic, and we are conservative.
with a "HAVING" clause though query works
SELECT from views defined like:
CREATE VIEW v1 (view_column)
AS SELECT c AS alias FROM t1 HAVING alias
fails with an error 1356:
View '...' references invalid table(s) or column(s)
or function(s) or definer/invoker of view lack rights
to use them
CREATE VIEW form with a (column list) substitutes
SELECT column names/aliases with names from a
view column list.
However, alias references in HAVING clause was
not substituted.
The Item_ref::print function has been modified
to write correct aliased names of underlying
items into VIEW definition generation/.frm file.
mysql-test/r/view.result:
Added test file for bug #40825.
mysql-test/t/view.test:
Added test file for bug #40825.
sql/item.cc:
Bug#40825: Error 1356 while selecting from a view
with a "HAVING" clause though query works
The Item_ref::print function has been modified
to write correct aliased names of underlying
items into VIEW definition generation/.frm file.
The RAND(N) function where the N is a field of "constant" table
(table of single row) failed with a SIGFPE.
Evaluation of RAND(N) rely on constant status of its argument.
Current server "seeded" random value for each constant argument
only once, in the Item_func_rand::fix_fields method.
Then the server skipped a call to seed_random() in the
Item_func_rand::val_real method for such constant arguments.
However, non-constant state of an argument may be changed
after the call to fix_fields, if an argument is a field of
"constant" table. Thus, pre-initialization of random value
in the fix_fields method is too early.
Initialization of random value by seed_random() has been
removed from Item_func_rand::fix_fields method.
The Item_func_rand::val_real method has been modified to
call seed_random() on the first evaluation of this method
if an argument is a function.
mysql-test/r/func_math.result:
Added test case for bug #44768.
mysql-test/t/func_math.test:
Added test case for bug #44768.
sql/item_func.cc:
Bug #44768: SIGFPE crash when selecting rand from a view containing null
1. Initialization of random value by seed_random() has been
removed from Item_func_rand::fix_fields method.
2. The Item_func_rand::val_real method has been modified to
call seed_random() on the first evaluation of this method
if an argument is a function.
sql/item_func.h:
Bug #44768: SIGFPE crash when selecting rand from a view containing null
1. The Item_func_rand::first_eval has been added to trace
the first evaluation of the val_real method.
2. The Item_func_rand::cleanup method has been added to
cleanup the first_eval flag.
always rollsback.
The global variable max_binlog_cache_size cannot be set more than 4GB on
32 bit systems, limiting transactions of all storage engines to 4G of changes.
The problem is max_binlog_cache_size is declared as ulong which is 4 bytes
on 32 bit and 8 bytes on 64 bit machines.
Fixed by using ulonglong for max_binlog_cache_size which is 8bytes on 32
and 64 bit machines.The range for max_binlog_cache_size on 32 bit and 64 bit
systems is 4096-18446744073709547520 bytes.
mysql-test/r/variables.result:
Result file for BUG#10206
mysql-test/t/variables.test:
Testcase for BUG#10206
sql/mysql_priv.h:
change the extern declaration of max_binlog_cache_size to ulonglong
sql/mysqld.cc:
change the declaration of max_binlog_cache_size to ulonglong and the option is fixed to extend the range of max_binlog_cache_size
sql/set_var.cc:
change the variable declaration of max_binlog_cache_size to ulonglong
Field_time::get_time() did not initialize some members of
MYSQL_TIME which led to valgrind warnings when those members
were accessed in Protocol_simple::store_time().
It is unlikely that this bug could result in wrong data
being returned, since Field_time::get_time() initializes the
'day' member of MYSQL_TIME to 0, so the value of 'day'
in Protocol_simple::store_time() would be 0 regardless
of the values for 'year' and 'month'.
mysql-test/r/type_time.result:
Added a test case for bug #44792.
mysql-test/t/type_time.test:
Added a test case for bug #44792.
sql/field.cc:
Field_time::get_time() did not initialize some members of
MYSQL_TIME which led to valgrind warnings when those members
were accessed in Protocol_simple::store_time().
In UNION if we use last SELECT without braces and this
SELECT have ORDER BY clause, such clause belongs to
global UNION. It is parsed like last SELECT
part and used further as 'unit->global_parameters->order_list' value.
During DESCRIBE EXTENDED we call select_lex->print_order() for
last SELECT where order fields refer to tmp table
which already freed. It leads to crash.
The fix is clean up global_parameters->order_list
instead of fake_select_lex->order_list.
mysql-test/r/union.result:
test result
mysql-test/t/union.test:
test case
sql/sql_union.cc:
In UNION if we use last SELECT without braces and this
SELECT have ORDER BY clause, such clause belongs to
global UNION. It is parsed like last SELECT
part and used further as 'unit->global_parameters->order_list' value.
During DESCRIBE EXTENDED we call select_lex->print_order() for
last SELECT where order fields refer to tmp table
which already freed. It leads to crash.
The fix is clean up global_parameters->order_list
instead of fake_select_lex->order_list.
It is not possible to prevent the server from starting if a mandatory
built-in plugin fails to start. This can in some cases lead to data
corruption when the old table name space suddenly is used by a different
storage engine.
A boolean command line option in the form of --foobar is automatically
created for every existing plugin "foobar". By changing this command line
option from a boolean to a tristate { OFF, ON, FORCE } it is possible to
specify the plugin loading policy for each plugin.
The behavior is specified as follows:
OFF = Disable the plugin and start the server
ON = Enable the plugin and start the server even if an error occurrs
during plugin initialization.
FORCE = Enable the plugin but don't start the server if an error occurrs
during plugin initialization.
mysql-test/lib/mtr_cases.pm:
* Changed --<pluginname> from a boolean to a tristate.
mysys/my_getopt.c:
* Changed --<pluginname> from boolean to tristate. Optional arguments
must still work for tristates. It is praxis that disable means value 0
and enable is value 1. Since plugin name is the only tristate with
optional arguments this principle will still hold.
sql/sql_plugin.cc:
* Changed --<pluginname> option from a boolean type to a tristate.
- FORCE will now terminate the server if the plugin fails to
initialize properly.
* Refactored prototypes for test_plugin_options() and construct_options()
to get rid of the 'enable' value pointer.
* Cleaned up code related to option name constructing.
* Added documentation
sql/sql_plugin.h:
* Introduced new member to st_plugin_int structure.
SQL_SELECT::test_quick_select
The crash was caused by an incomplete cleanup of JOIN_TAB::select
during the filesort of rows for GROUP BY clause inside a subquery.
Queries where a quick index access is replaced with filesort was
was affected. For example:
SELECT 1 FROM
(SELECT COUNT(DISTINCT c1) FROM t1
WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x
Quick index access related data in the SQL_SELECT::test_quick_select
function was inconsistent after an incomplete cleanup.
This function has been completed to prevent crashes in the
SQL_SELECT::test_quick_select function.
mysql-test/include/mix1.inc:
Add test case for bug #44290.
mysql-test/r/innodb_mysql.result:
Add test case for bug #44290.
sql/sql_select.cc:
Bug #44290: explain crashes for subquery with distinct in
SQL_SELECT::test_quick_select
Quick index access related data in the SQL_SELECT::test_quick_select
function was inconsistent after an incomplete cleanup.
This function has been completed to prevent crashes in the
SQL_SELECT::test_quick_select function.
and HAVING
When calculating GROUP BY the server caches some expressions. It does
that by allocating a string slot (Item_copy_string) and assigning the
value of the expression to it. This effectively means that the result
type of the expression can be changed from whatever it was to a string.
As this substitution takes place after the compile-time result type
calculation for IN but before the run-time type calculations,
it causes the type calculations in the IN function done at run time
to get unexpected results different from what was prepared at compile time.
In the CASE ... WHEN ... THEN ... statement there was a similar problem
and it was solved by artificially adding a STRING argument to the matrix
at compile time, so if any of the arguments of the CASE function changes
its type to a string it will still be covered by the information prepared
at compile time.
Extended the CASE fix for cover the IN case.
An alternative way of fixing this problem is by caching the result type of
the arguments at compile time and using the cached information at run time
instead of re-calculating the result types.
Preferred the CASE approach for uniformity and fix localization.
mysql-test/r/func_in.result:
Bug #44399: test case
mysql-test/t/func_in.test:
Bug #44399: test case
sql/item_cmpfunc.cc:
Bug #44399: assume at compile time there's an extra string argument
in the IN function (similar to CASE) to cater for possible string
conversions in the process of calculating the GROUP BY/aggregates.
Problem: executing queries like "ALTER TABLE view1;" we don't
check new view's name (which is not specified),
that leads to server crash.
Fix: do nothing (to be consistent with the behaviour for tables)
in such cases.
mysql-test/r/view.result:
Fix for bug#44860: ALTER TABLE on view crashes server
- test result.
mysql-test/t/view.test:
Fix for bug#44860: ALTER TABLE on view crashes server
- test case.
sql/sql_rename.cc:
Fix for bug#44860: ALTER TABLE on view crashes server
- do_rename(): new view/table name must be specified, ASSERT() added.
sql/sql_table.cc:
Fix for bug#44860: ALTER TABLE on view crashes server
- mysql_alter_table(): renaming a view, check if new
view name is specified.
"freeing items"
The calculation of the table map log event in the event constructor
was one byte shorter than what would be actually written. This would
lead to a mismatch between the number of bytes written and the event
end_log_pos, causing bad event alignment in the binlog (corrupted
binlog) or in the transaction cache while fixing positions
(MYSQL_BIN_LOG::write_cache). This could lead to impossible to read
binlog or even infinite loops in MYSQL_BIN_LOG::write_cache.
This patch addresses this issue by correcting the expected event
length in the Table_map_log_event constructor, when the field metadata
size exceeds 255.
sql/log_event.cc:
Added the extra byte as net_store_length imposes.
Problem: using LOAD_FILE() in some cases we pass a file name string
without a trailing '\0' to fn_format() which relies on that however.
That may lead to valgrind warnings.
Fix: add a trailing '\0' to the file name passed to fn_format().
mysql-test/r/func_str.result:
Fix for bug#44774: load_file function produces valgrind warnings
- test result.
mysql-test/t/func_str.test:
Fix for bug#44774: load_file function produces valgrind warnings
- test case.
sql/item_strfunc.cc:
Fix for bug#44774: load_file function produces valgrind warnings
- passing a file name to fn_format(), file_name->c_ptr() replaced
with file_name->c_ptr_safe() to ensure we have a trailing '\0'.
The problem is that the internal variable used to specify a
transaction with consistent read was being used outside the
processing context of a START TRANSACTION WITH CONSISTENT
SNAPSHOT statement. The practical consequence was that a
consistent snapshot specification could leak to unrelated
transactions on the same session.
The solution is to ensure a consistent snapshot clause is
only relied upon for the START TRANSACTION statement.
This is already fixed in a similar way on 6.0.
mysql-test/r/consistent_snapshot.result:
Add test case result for Bug#44664
mysql-test/t/consistent_snapshot.test:
Add test case for Bug#44664
sql/sql_parse.cc:
The WITH CONSISTENT SNAPSHOT clause is only valid for the
START TRANSACTION statement.
SQL_SELECT::test_quick_select
The crash was caused by an incomplete cleanup of JOIN_TAB::select
during the filesort of rows for GROUP BY clause inside a subquery.
Queries where a quick index access is replaced with filesort was
was affected. For example:
SELECT 1 FROM
(SELECT COUNT(DISTINCT c1) FROM t1
WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x
Quick index access related data in the SQL_SELECT::test_quick_select
function was inconsistent after an incomplete cleanup.
This function has been completed to prevent crashes in the
SQL_SELECT::test_quick_select function.
mysql-test/include/mix1.inc:
Add test case for bug #44290.
mysql-test/r/innodb_mysql.result:
Add test case for bug #44290.
sql/sql_select.cc:
Bug #44290: explain crashes for subquery with distinct in
SQL_SELECT::test_quick_select
Quick index access related data in the SQL_SELECT::test_quick_select
function was inconsistent after an incomplete cleanup.
This function has been completed to prevent crashes in the
SQL_SELECT::test_quick_select function.
In the output from mysqlbinlog, incident log events were
represented as just a comment. Since the incident log event
represents an incident that could cause the contents of the
database to change without being logged to the binary log,
it means that if the SQL is applied to a server, it could
potentially lead to that the databases are out of sync.
In order to handle that, this patch adds the statement "RELOAD
DATABASE" to the SQL output for the incident log event. This will
require a DBA to edit the file and handle the case as apropriate
before applying the output to a server.
mysql-test/suite/binlog/t/binlog_incident-master.opt:
Options file to cause server to generate an incident log
event when executing a REPLACE.
mysql-test/suite/binlog/t/binlog_incident.test:
Test to check that the incident log event is represented
correctly in the output from mysqlbinlog.
sql/log_event.cc:
The incident log event now ouput a "RELOAD DATABASE" instead
of just a comment. RELOAD DATABASE is not an existing command
and will generate a syntax error.
Problem: storing "SELECT ... INTO @var ..." results in variables we used val_xxx()
methods which returned results of the current row.
So, in some cases (e.g. SELECT DISTINCT, GROUP BY or HAVING) we got data
from the first row of a new group (where we evaluate a clause) instead of
data from the last row of the previous group.
Fix: use val_xxx_result() counterparts to get proper results.
mysql-test/r/distinct.result:
Fix for bug#42009: SELECT into variable gives different results to direct SELECT
- results adjusted.
mysql-test/r/user_var.result:
Fix for bug#42009: SELECT into variable gives different results to direct SELECT
- test result.
mysql-test/t/user_var.test:
Fix for bug#42009: SELECT into variable gives different results to direct SELECT
- test case.
sql/item_func.cc:
Fix for bug#42009: SELECT into variable gives different results to direct SELECT
- Item_func_set_user_var::save_item_result() added to evaluate and store
an item's result into a user variable.
sql/item_func.h:
Fix for bug#42009: SELECT into variable gives different results to direct SELECT
- Item_func_set_user_var::save_item_result() added to evaluate and store
an item's result into a user variable.
sql/sql_class.cc:
Fix for bug#42009: SELECT into variable gives different results to direct SELECT
- use Item_func_set_user_var::save_item_result() to store results into user
variables.
165 changesets with 23 conflicts:
Text conflict in mysql-test/r/lock_multi.result
Text conflict in mysql-test/t/lock_multi.test
Text conflict in mysql-test/t/mysqldump.test
Text conflict in sql/item_strfunc.cc
Text conflict in sql/log.cc
Text conflict in sql/log_event.cc
Text conflict in sql/parse_file.cc
Text conflict in sql/slave.cc
Text conflict in sql/sp.cc
Text conflict in sql/sp_head.cc
Text conflict in sql/sql_acl.cc
Text conflict in sql/sql_base.cc
Text conflict in sql/sql_class.cc
Text conflict in sql/sql_crypt.cc
Text conflict in sql/sql_db.cc
Text conflict in sql/sql_lex.cc
Text conflict in sql/sql_parse.cc
Text conflict in sql/sql_select.cc
Text conflict in sql/sql_table.cc
Text conflict in sql/sql_view.cc
Text conflict in storage/innobase/handler/ha_innodb.cc
Text conflict in storage/myisam/mi_packrec.c
Text conflict in tests/mysql_client_test.c
Updates to Innobase, taken from main 5.1:
bzr: ERROR: Some change isn't sane:
File mysql-test/r/innodb-semi-consistent.result is owned by Innobase and should not be updated.
File mysql-test/t/innodb-semi-consistent.test is owned by Innobase and should not be updated.
File storage/innobase/handler/ha_innodb.cc is owned by Innobase and should not be updated.
File storage/innobase/ibuf/ibuf0ibuf.c is owned by Innobase and should not be updated.
File storage/innobase/include/row0mysql.h is owned by Innobase and should not be updated.
File storage/innobase/include/srv0srv.h is owned by Innobase and should not be updated.
File storage/innobase/include/trx0trx.h is owned by Innobase and should not be updated.
File storage/innobase/include/trx0trx.ic is owned by Innobase and should not be updated.
File storage/innobase/lock/lock0lock.c is owned by Innobase and should not be updated.
File storage/innobase/page/page0cur.c is owned by Innobase and should not be updated.
File storage/innobase/row/row0mysql.c is owned by Innobase and should not be updated.
File storage/innobase/row/row0sel.c is owned by Innobase and should not be updated.
File storage/innobase/srv/srv0srv.c is owned by Innobase and should not be updated.
File storage/innobase/trx/trx0trx.c is owned by Innobase and should not be updated.
(Set env var 'ALLOW_UPDATE_INNOBASE_OWNED' to override.)
with seg fault
Multiple-table DELETE from a table joined to itself may cause
server crash. This was originally discovered with MEMORY engine,
but may affect other engines with different symptoms.
The problem was that the server violated SE API by performing
parallel table scan in one handler and removing records in
another (delete on the fly optimization).
mysql-test/r/heap_btree.result:
Updated test result after adding new test for this bug.
mysql-test/t/heap_btree.test:
Updated test result after adding new test for the bug report.
sql/sql_delete.cc:
Updated to check if the files in delete list appears in join list and disable
delete while scanning, if it appears.
Certain multi-updates gave different results on InnoDB from
to MyISAM, due to on-the-fly updates being used on the former and
the update order matters.
Fixed by turning off on-the-fly updates when update order
dependencies are present.
mysql-test/r/innodb_mysql.result:
Bug#43580: Test result.
mysql-test/suite/rpl/r/rpl_slave_skip.result:
Bug#43580: Changed test result. The InnoDB result is now what it would have been on MyISAM.
mysql-test/t/innodb_mysql.test:
Bug#43580: Test case.
sql/sql_base.cc:
Bug#43580: Added a word of caution about using tmp_set here.
sql/sql_update.cc:
Bug#43580: Fix.
Calls to TABLE::mark_columns_needed_for_update() are moved
from mysql_multi_update_prepare() and right before the decison
to do on-the-fly updates to the place where we do (or don't do)
on-the-fly updates.
'INSERT ... SELECT' statements
The code that produces result rows expected that a duplicate row
error could not occur in INSERT ... SELECT statements with
unfulfilled WHERE conditions. This may happen, however, if the
SELECT list contains only aggregate functions.
Fixed by checking if an error occured before trying to send EOF
to the client.
mysql-test/r/insert_select.result:
Bug#44306: Test result
mysql-test/t/insert_select.test:
Bug#44306: Test case
sql/sql_select.cc:
Bug#44306: Fix
A backport of fix for "BUG40092 - Storage engine API uses
time_t datatype".
Starting from MSVC C++ 2005 (v8), the default size of time_t
is changed from 32-bit to 64-bit. As the result, the binaries
built with pre-v8 MSVC C++ do not work with the binaries
(storage engine plugins) built with v8 or after (server
crashes).
Fixed storage engine API to use datatype with known size
(ulong) instead of time_t.
sql/handler.h:
Bug#39802 On Windows, 32-bit time_t should be enforced
Change create_time, check_time, update_time
in the ha_statistics and PARTITION_INFO
structures to ulong.
EXPLAIN EXTENDED of nested query containing a error:
1054 Unknown column '...' in 'field list'
may cause a server crash.
Parse error like described above forces a call to
JOIN::destroy() on malformed subquery.
That JOIN::destroy function closes and frees temporary
tables. However, temporary fields of these tables
may be listed in st_select_lex::group_list of outer
query, and that st_select_lex may not cleanup them
properly. So, after the JOIN::destroy call that
st_select_lex::group_list may have Item_field
objects with dangling pointers to freed temporary
table Field objects. That caused a crash.
mysql-test/r/subselect3.result:
Added test case for bug #37362.
mysql-test/t/subselect3.test:
Added test case for bug #37362.
sql/sql_select.cc:
Bug #37362: Crash in do_field_eq
The JOIN::destroy function has been modified to
cleanup temporary table column items.
my_error() was invoked in reset_slave()'s with purge_relay_logs()-failing branch
without passing sql_errno to it.
Fixed with setting sql_errno= ER_RELAY_LOG_FAIL in the purge_relay_logs()-failing branch.
sql/sql_repl.cc:
set sql_errno= ER_RELAY_LOG_FAIL when purge_relay_logs() fails.
Error happens because sp_head::MULTI_RESULTS is not set for SP
which has 'show table status' command.
The fix is to add a SQLCOM_SHOW_TABLE_STATUS case into
sp_get_flags_for_command() func.
mysql-test/r/sp.result:
test result
mysql-test/t/sp.test:
test case
sql/sp_head.cc:
Error happens because sp_head::MULTI_RESULTS is not set for SP
which has 'show table status' command.
The fix is to add a SQLCOM_SHOW_TABLE_STATUS case into
sp_get_flags_for_command() func.
The issue of the current bug is unguarded access to mi->slave_running
by the shutdown thread calling end_slave() that is bug#29968
(alas happened not to be cross-linked with the current bug)
Fixed:
with removing the unguarded read of the running status
and perform reading it in terminate_slave_thread()
at time run_lock is taken (mostly bug#29968 backporting, still with some
improvements over that patch - see the error reporting from
terminate_slave_thread()).
Issue of bug#38716 is fixed here for 5.0 branch as well.
Note:
There has been a separate artifact identified -
a race condition between init_slave() and end_slave() -
reported as Bug#44467.
mysql-test/r/rpl_bug38694.result:
a new results file is added.
mysql-test/t/rpl_bug38694-slave.opt:
simulating delay at slave threads shutdown.
mysql-test/t/rpl_bug38694.test:
A new test to check if a delay at the termination phase of slave threads
could cause any issue.
sql/slave.cc:
The unguarded read of the running status is removed. Its reading is done in
terminate_slave_thread() at time run_lock is taken;
Calling terminate_slave_threads(skip_lock := !need_slave_mutex) in the failing branch of start_slave_threads() which is bug#38716 issue.
sql/slave.h:
removing terminate_slave_thread() out of the global interface scope.
the Point() and Linestring() functions create WKB representation of an
object instead of an real geometry object.
That produced bugs when these were inserted into tables.
GIS tests fixed accordingly.
per-file messages:
mysql-test/r/gis-rtree.result
Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash
test result
mysql-test/r/gis.result
Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash
test result
mysql-test/t/gis-rtree.test
Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash
test fixed - GeomFromWKB invocations removed
mysql-test/t/gis.test
Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash
test fixed - AsWKB invocations added
sql/item_geofunc.cc
Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash
Point() and similar functions to create a proper object
Bug #40925: Equality propagation takes non indexed attribute
Query execution plans and execution time of queries like
select a, b, c from t1
where a > '2008-11-21' and b = a limit 10
depended on the order of equality operator parameters:
"b = a" and "a = b" are not same.
An equality propagation algorithm has been fixed:
the substitute_for_best_equal_field function should not
substitute a field for an equal field if both fields belong
to the same table.
mysql-test/r/select.result:
Added test case for bug #40925.
mysql-test/t/select.test:
Added test case for bug #40925.
sql/item.cc:
Bug #40925: Equality propagation takes non indexed attribute
An equality propagation algorithm has been fixed:
the substitute_for_best_equal_field function should not
substitute a field for an equal field if both fields belong
to the same table.
for indexes of InnoDB table
Fixes by replacing the PRNG that is used to pick random pages with a
better one.
Also adds a configuration option "innodb_use_legacy_cardinality_algorithm"
to enable the fix only when the option is set.
This patch is from http://bugs.mysql.com/file.php?id=11789
replaced String->c_ptr() with String->c_ptr_safe()
mysql-test/r/func_encrypt.result:
test result
mysql-test/t/func_encrypt.test:
test case
sql/item_strfunc.cc:
replaced String->c_ptr() with String->c_ptr_safe()
The warning happens because string argument is not zero ended.
The fix is to add new parameter 'length' to SQL_CRYPT() and
use ptr() instead of c_ptr().
mysql-test/r/func_str.result:
test result
mysql-test/t/func_str.test:
test case
sql/item_strfunc.cc:
Added new parameter 'length' to SQL_CRYPT
sql/sql_crypt.cc:
Added new parameter 'length' to SQL_CRYPT
sql/sql_crypt.h:
Added new parameter 'length' to SQL_CRYPT
The rpl_binlog_corruption test case was inject failures, specifically,
incidents with invalid numbers to see if the replication was failing
gracefully. However, this test was causing the following warning message
in Valgrind: "Conditional jump or move depends on uninitialised value(s)"
The patch fixes the problem by correctly initializing the m_inicident
number.
In order to define the --slave-load-tmpdir, the init_relay_log_file()
was calling fn_format(MY_PACK_FILENAME) which internally was indirectly
calling strmov_overlapp() (through pack_dirname) and the following
warning message was being printed out while running in Valgrind:
"source and destination overlap in strcpy".
We fixed the issue by removing the flag MY_PACK_FILENAME as it was not
necessary. In a nutshell, with this flag the function fn_format() tried
to replace a directory by either "~", "." or "..". However, we wanted
exactly to remove such strings.
In this patch, we also refactored the functions init_relay_log_file()
and check_temp_dir(). The former was refactored to call the fn_format()
with the flag MY_SAFE_PATH along with the MY_RETURN_REAL_PATH, in order
to avoid issues with long directories and return an absolute path,
respectively. The flag MY_SAFE_UNPACK_FILENAME was removed too as it was
responsible for removing "~", "." or ".." only from the file parameter
and we wanted to remove such strings from the directory parameter in
the fn_format(). This result is stored in an rli variable, which is then
processed by the other function in order to verify if the directory exists
and if we are able to create files in it.
mysql-test/suite/rpl/t/rpl_slave_load_tmpdir_not_exist.test:
Changed the output to make it consistent among different runs.
mysys/mf_format.c:
Replaced a return for DBUG_RETURN.
to wrong results
3 problems found with DES_ENCRYPT/DES_DECRYPT :
1. The max length was not calculated properly. Fixed in fix_length_and_dec()
2. DES_ENCRYPT had a side effect of sometimes reallocating and changing
the value of its argument. Fixed by explicitly pre-allocating the necessary
space to pad the argument with trailing '*' (stars) when calculating the
DES digest.
3. in DES_ENCRYPT the string buffer for the result value was not
reallocated to the correct size and only string length was assigned to it.
Fixed by making sure there's enough space to hold the result.
information schema tables are based on internal tmp tables which are removed
after each statement execution. So HANDLER comands can not be used with
information schema.
mysql-test/r/handler.result:
test result
mysql-test/t/handler.test:
test case
sql/sql_handler.cc:
information schema tables are based on internal tmp tables which are removed
after each statement execution. So HANDLER comands can not be used with
information schema.
using it.
The crash was due to a null pointer present for select_lex while
processing the view.
Adding a check while opening the view to see if its a child of a
merge table fixed this problem.
mysql-test/r/merge.result:
Updated result for the new test case.
mysql-test/t/merge.test:
Added test case based on the bug description.
sql/sql_base.cc:
Added a check to check if the view being opened is a child table of a
merge table and return error if it is.
The problem was that new lock types were being added without a
corresponding description. Since the lock types (enum values)
are used as indices to the description array, the descriptions
could be shifted depending on the lock type. The solution is to
ensure that every lock type has a correspondent description.
include/thr_lock.h:
Add warning.
sql/sql_test.cc:
Update lock descriptions.
Engine doesn't allow me to.
In case of incompatible changes between old and new table
versions, the mysqlcheck program prints error messages like
this:
error: Table upgrade required. Please do
"REPAIR TABLE `table_name`" to fix it!
However, InnoDB doesn't support REPAIR TABLE query, so the
message is confusing.
Error message text has been changed to:
Table upgrade required. Please do "REPAIR TABLE `table_name`"
or dump/reload to fix it!"
mysql-test/r/repair.result:
Updated test case for bug #42563.
mysql-test/r/varbinary.result:
Updated test case for bug #42563.
sql/share/errmsg.txt:
Bug #42563: Message tells me to repair table though Storage
Engine doesn't allow me to.
The ER_TABLE_NEEDS_UPGRADE error message has been changed to:
Table upgrade required. Please do "REPAIR TABLE ``%-.32s`"
or dump/reload to fix it!"
mysql_rename_view can not rename view if database is not the same.
The fix is to add new argument 'new_db' to mysql_rename_view() and
allow rename with different databases
(only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).
mysql-test/t/upgrade.test:
test fix
sql/parse_file.cc:
mysql_rename_view can not rename view if database is not the same.
The fix is to add new argument 'new_db' to mysql_rename_view() and
allow rename with different databases
(only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).
sql/parse_file.h:
mysql_rename_view can not rename view if database is not the same.
The fix is to add new argument 'new_db' to mysql_rename_view() and
allow rename with different databases
(only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).
sql/sql_rename.cc:
mysql_rename_view can not rename view if database is not the same.
The fix is to add new argument 'new_db' to mysql_rename_view() and
allow rename with different databases
(only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).
sql/sql_view.cc:
mysql_rename_view can not rename view if database is not the same.
The fix is to add new argument 'new_db' to mysql_rename_view() and
allow rename with different databases
(only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).
sql/sql_view.h:
mysql_rename_view can not rename view if database is not the same.
The fix is to add new argument 'new_db' to mysql_rename_view() and
allow rename with different databases
(only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).
allow 'rename view' for ALTER ...UPGRADE DATA DIRECTORY NAME command.
it's safe because a view has valid internal db&table names in this case.
mysql-test/r/upgrade.result:
test result
mysql-test/t/upgrade.test:
test case
sql/sql_rename.cc:
allow 'rename view' for ALTER ...UPGRADE DATA DIRECTORY NAME command.
it's safe because a view has valid internal db&table names in this case.
comment can't be read back
A change to the lexer in 5.1 caused slash-asterisk-bang-version
sections to be terminated early if there exists a slash-asterisk-
style comment inside it. Nesting comments is usually illegal,
but we rely on versioned comment blocks in mysqldump, and the
contents of those sections must be allowed to have comments.
The problem was that when encountering open-comment tokens and
consuming -or- passing through the contents, the "in_comment"
state at the end was clobbered with the not-in-a-comment value,
regardless of whether we were in a comment before this or not.
So, """/*!VER one /* two */ three */""" would lose its in-comment
state between "two" and "three". Save the echo and in-comment
state, and restore it at the end of the comment if we consume a
comment.
Bug#44091: libmysqld gets stuck waiting on mutex on initialization
The problem was that libmysqld wasn't enforcing a certain
initialization and deinitialization order for the mysys
library. Another problem was that the global object used
for management of log event handlers (aka LOGGER) wasn't
being prepared for a possible reutilization.
What leads to the hang/crash reported is that a failure
to load the language file triggers a double call of the
cleanup functions, causing an already destroyed mutex to
be used.
The solution is enforce a order on the initialization and
deinitialization of the mysys library within the libmysqld
library and to ensure that the global LOGGER object reset
it's internal state during cleanup.
mysys/my_init.c:
Deinitialize only if initialized already.
sql/log.cc:
Reset state.
routine does not exist
There is an inconsistency with DROP DATABASE IF EXISTS, DROP TABLE IF
EXISTS and DROP VIEW IF EXISTS: those are binlogged even if the DB or
TABLE does not exist, whereas DROP PROCEDURE IF EXISTS does not. It
would be nice or at least consistent if DROP PROCEDURE/STATEMENT
worked the same too.
Fixed DROP PROCEDURE|FUNCTION IF EXISTS by adding a call to
mysql_bin_log.write in mysql_execute_command. Checked also if all
documented "DROP (...) IF EXISTS" get binlogged.
NOTE: This is a 5.0 backport patch as requested by support.
mysql-test/r/rpl_drop_if_exists.result:
Result file for test case added.
mysql-test/r/rpl_sp.result:
Updated result file for existing test case that has now extra events in
binary log (the ones from drop if exists procedure/function).
mysql-test/t/rpl_drop_if_exists.test:
Added test case for asserting validity of proposed patch.
sql/sql_parse.cc:
Added call mysql_bin_log.write when lex has drop_if_exists enabled for
stored procedures.
The crash happens due to wrong 'digits' variable value(0),
'digits' can not be 0, so the fix is use 1 as min allowed value.
mysql-test/r/insert.result:
test result
mysql-test/t/insert.test:
test case
sql/field.cc:
The crash happens due to wrong 'digits' variable value(0),
'digits' can not be 0, so the fix is use 1 as min allowed value.
Binlog the CREATE EVENT unless the created event been successfully dropped
Modified Query_log_event constructor to make sure that error_code
is not set to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED errors
when NOT_KILLED
sql/events.cc:
binlog the create event unless it's been successfully dropped
sql/log_event.cc:
Modified Query_log_event constructor to make sure that error_code
is not set to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED errors
when NOT_KILLED
We didn't expect "error: no error", although this is
in fact a legitimate state (if something is erroneous
on the master, but not on the slave, e.g. INSERT fails
on master due to UNIQUE constraint which does not exist
on slave).
We now list the ignore for "0: no error" the same way
as any other ignore; moreover, if no or an empty
--slave-skip-errors is passed at start-up, we show
"OFF" instead of empty list, as intended. (The code
for that was there, but was only run for the empty-
argument case, even if it subsequently tested for
both conditions.)
mysql-test/r/not_embedded_server.result:
Show that passing no --slave-skip-errors results
in "OFF" being shown as the variable's value. This
test's "twin" (also not embedded, but setting
--slave-skip-errors in its -opt file) lives in
variables-notembbeded.test.
mysql-test/r/variables-notembedded.result:
Show that error-ignore 0 is handled just like any other
ignore. This test's "twin" (also not embedded, but not
setting --slave-skip-errors in its -opt file) lives in
not_embbeded_server.test.
mysql-test/t/not_embedded_server.test:
Show that passing no --slave-skip-errors results
in "OFF" being shown as the variable's value.
mysql-test/t/variables-notembedded-master.opt:
Show that error-ignore 0 is handled just like any other
ignore.
sql/slave.cc:
- set up error-ignore-info even if --slave-skip-errors
was not passed at start-up.
- handle error 0 just like any other error.
RBR was not considering the option --slave-skip-errors.
To fix the problem, we are reporting the ignored ERROR(s) as warnings thus avoiding
stopping the SQL Thread. Besides, it fixes the output of "SHOW VARIABLES LIKE
'slave_skip_errors'" which was showing nothing when the value "all" was assigned
to --slave-skip-errors.
@sql/log_event.cc
skipped rbr errors when the option skip-slave-errors is set.
@sql/slave.cc
fixed the output of for SHOW VARIABLES LIKE 'slave_skip_errors'"
@test-cases
fixed the output of rpl.rpl_idempotency
updated the test case rpl_skip_error
The problem is that a SELECT .. FOR UPDATE statement might open
a table and later wait for a impeding global read lock without
noticing whether it is holding a table that is being waited upon
the the flush phase of the process that took the global read
lock.
The same problem also affected the following statements:
LOCK TABLES .. WRITE
UPDATE .. SET (update and multi-table update)
TRUNCATE TABLE ..
LOAD DATA ..
The solution is to make the above statements wait for a impending
global read lock before opening the tables. If there is no
impending global read lock, the statement raises a temporary
protection against global read locks and progresses smoothly
towards completion.
Important notice: the patch does not try to address all possible
cases, only those which are common and can be fixed unintrusively
enough for 5.0.
mysql-test/r/lock_multi.result:
Add test case result for Bug#43230
mysql-test/t/lock_multi.test:
Add test case for Bug#43230
sql/sql_lex.cc:
Initialize flag.
sql/sql_lex.h:
Add a flag to the lexer.
sql/sql_parse.cc:
Wait for the global read lock is a write lock is going to be
taken. The wait is done before opening tables.
sql/sql_yacc.yy:
Protect against the GRL if its a SELECT .. FOR UPDATE or LOCK TABLES
.. WRITE statement.
Mysql server crashes because unsafe statements warning is wrongly elevated to error,
which is set the error status of Diagnostics_area of the thread in THD::binlog_query().
Yet the caller believes that binary logging shouldn't touch the status, so it will
set the status also later by my_ok(), my_error() or my_message() seperately
according to the execution result of the statement or transaction.
But the status of Diagnostics_area of the thread is allowed to set only once.
Fixed to clear the error wrongly set by binary logging, but keep the warning message.
mysql-test/suite/binlog/r/binlog_stm_ps.result:
Change unsafe warning to NOTE level
mysql-test/suite/binlog/r/binlog_unsafe.result:
Test case result for unsafe statements to ensure mysql sever don't crash
mysql-test/suite/binlog/t/binlog_unsafe.test:
Test case for unsafe statements to ensure mysql sever don't crash
mysql-test/suite/rpl/r/rpl_skip_error.result:
Change unsafe warning to NOTE level
mysql-test/suite/rpl/r/rpl_stm_loadfile.result:
Change unsafe warning to NOTE level
mysql-test/suite/rpl/r/rpl_udf.result:
Change unsafe warning to NOTE level
sql/sql_class.cc:
the error status of the thread is cleared When a warning is elevated to an error
because of unsafe warning of binary log.
Original commentary:
Bug #37348: Crash in or immediately after JOIN::make_sum_func_list
The optimizer pulls up aggregate functions which should be aggregated in
an outer select. At some point it may substitute such a function for a field
in the temporary table. The setup_copy_fields function doesn't take this
into account and may overrun the copy_field buffer.
Fixed by filtering out the fields referenced through the specialized
reference for aggregates (Item_aggregate_ref).
Added an assertion to make sure bugs that cause similar discrepancy
don't go undetected.
mysql-test/r/func_group.result:
Backport bug #37348 fix 5.1 --> 5.0.
mysql-test/t/func_group.test:
Backport bug #37348 fix 5.1 --> 5.0.
sql/item.cc:
Backport bug #37348 fix 5.1 --> 5.0.
sql/item.h:
Backport bug #37348 fix 5.1 --> 5.0.
sql/sql_select.cc:
Backport bug #37348 fix 5.1 --> 5.0.
The problem is that XML functions(items) do not reset null_value
before their execution and further item excution may use
null_value value of the previous result.
The fix is to reset null_value.
mysql-test/r/xml.result:
test result
mysql-test/t/xml.test:
test case
sql/item_xmlfunc.cc:
The problem is that XML functions(items) do not reset null_value
before their execution and further item excution may use
null_value value of the previous result.
The fix is to reset null_value.
Problem: we don't prune a LESS THAN partition if MAXVALUE is given and
given value is equal to a LESS THAN value.
Fix: prune partitions in such cases.
mysql-test/r/partition.result:
Fix for bug#42944: partition not pruned correctly
- test result.
mysql-test/t/partition.test:
Fix for bug#42944: partition not pruned correctly
- test case.
sql/sql_partition.cc:
Fix for bug#42944: partition not pruned correctly
- prune partition if given value is equal to a LESS THAN value
and it's not a "PARTITION ... LESS THAN MAXVALUE" one.
on 5.0
The server crashes on an assert in net_end_statement indicating that the
Diagnostics area wasn't set properly during execution.
This happened on a multi table DELETE operation using the IGNORE keyword.
The keyword is suppose to allow for execution to continue on a best effort
despite some non-fatal errors. Instead execution stopped and no client
response was sent which would have led to a protocol error if it hadn't been
for the assert.
This patch corrects this issue by checking for the existence of an IGNORE
option before setting an error state during row-by-row delete iteration.
mysql-test/r/innodb_mysql.result:
* Added test case for bug40127
mysql-test/t/innodb_mysql.test:
* Added test case for bug40127
sql/sql_delete.cc:
* IGNORE option wasn't implemented in multi_delete::send_data
and multi_delete::do_deletes
updates
Attempt to execute trigger or stored function with multi-UPDATE
which used - but didn't update - a table that was also used by
the calling statement led to an error. Read-only reference to
tables used in the calling statement should be allowed.
This problem was caused by the fact that check for conflicting
use of tables in SP/triggers was performed in open_tables(),
and in case of multi-UPDATE we didn't know exact lock type at
this stage.
We solve the problem by moving this check to lock_tables(), so
it can be performed after exact lock types for tables used by
multi-UPDATE are determined.
mysql-test/r/trigger.result:
Results for the added test case is added.
mysql-test/t/trigger.test:
A new test case is added, verifying correct table multi-update
conflict resolution, both read-only and write.
sql/sql_base.cc:
The check for conflicting use of tables in SP/triggers is moved
to lock_tables(), to be performed after the exact lock types
have been determined. Also, an assert is added to open_ltable()
to ensure this func is not used in a prelocked context.
UNION could convert fixed-point FLOAT(M,D)/DOUBLE(M,D) columns
to FLOAT/DOUBLE when aggregating data types from the SELECT
substatements. While there is nothing particularly wrong with
this behavior, especially when M is greater than the hardware
precision limits, it could be confusing in cases when all
SELECT statements in a union have the same
FLOAT(M,D)/DOUBLE(M,D) columns with equal precision
specifications listed in the same position.
Since the manual is quite vague on what data type should be
returned in such cases, the bug was fixed by implementing the
most 'expected' behavior: do not convert FLOAT(M,D)/DOUBLE(M,D)
to anything else if all SELECT statements in a UNION have the
same precision for that column.
mysql-test/r/union.result:
Added a test case for bug #43432.
mysql-test/t/union.test:
Added a test case for bug #43432.
sql/field.cc:
Replaced FLT_DIG+6 and DBL_DIG+7 with a symbolic constant.
sql/item.cc:
Do not convert FLOAT(M,D)/DOUBLE(M,D)
to anything else if all SELECT statements in a UNION have the
same precision for that column.
sql/mysql_priv.h:
Added a symbolic constant for FLT_DIG+6 and DBL_DIG+7.
Problem: commit doesn't delete savepoints if there are no changes
in the transaction.
Fix: delete them in such cases.
mysql-test/r/innodb_mysql.result:
Fix for bug #26288: savepoint not deleted, comit on empty transaction
- test result.
mysql-test/t/innodb_mysql.test:
Fix for bug #26288: savepoint not deleted, comit on empty transaction
- test case.
sql/handler.cc:
Fix for bug #26288: savepoint not deleted, comit on empty transaction
- call transaction.cleanup() even if nht is 0 to delete
possible savepoints.
When the thread executing a DDL was killed after finished its
execution but before writing the binlog event, the error code in
the binlog event could be set wrongly to ER_SERVER_SHUTDOWN or
ER_QUERY_INTERRUPTED.
This patch fixed the problem by ignoring the kill status when
constructing the event for DDL statements.
This patch also included the following changes in order to
provide the test case.
1) modified mysqltest to support variable for connection command
2) modified mysql-test-run.pl, add new variable MYSQL_SLAVE to
run mysql client against the slave mysqld.
Bug#319 if while a non-transactional slave is replicating a transaction possible problem
It is impossible to roll back a mixed engines transaction when one of the engine is
non-transaction. In replication that fact is crucial because the slave can not safely
re-apply a transction that was interrupted with STOP SLAVE.
Fixed with making STOP SLAVE not be effective immediately in the case the current
group of replication events has modified a non-transaction table. In order for slave to leave
either the group needs finishing or the user issues KILL QUERY|CONNECTION slave_thread_id.
mysql-test/suite/bugs/r/rpl_bug38205.result:
bug#38205 non-deterministic part of tests results.
mysql-test/suite/bugs/t/rpl_bug38205.test:
bug#38205 non-deterministic part of tests.
mysql-test/suite/rpl/r/rpl_start_stop_slave.result:
bug#38205 deterministic part of tests results.
mysql-test/suite/rpl/t/rpl_start_stop_slave-slave.opt:
increasing `innodb_lock_wait_timeout' to make the test pass on slow env w/o
timeout expired issue.
mysql-test/suite/rpl/t/rpl_start_stop_slave.test:
bug#38205 deterministic part of tests.
sql/log_event.cc:
Augmenting row-based events applying with the notion of
thd->transaction.{all,stmt}.modified_non_trans_table.
The pair is set and reset according to its specification
for the mixed transaction processing.
Particualry, once `modified_non_trans_table' is set in the row-events
processing loop, it will remain till the commit of the transaction.
sql/slave.cc:
Consulting `thd->transaction.all.modified_non_trans_table' to decide
whether to terminate by the sql thread or to continue even though
the sql thread might have been STOP-ed (rli->abort_slave).
When add an aliase name after NAME_CONST, the aliase name will be overwrite.
NAME_CONST will re-set the field's name only if there isn't an aliase in the
function fix-fields().
If there is an aliase, NAME_CONST doesn't re-set the field's name and keeps the old
name.
mysql-test/r/func_misc.result:
Test result.
mysql-test/r/rpl_name_const.result:
Test case.
mysql-test/t/func_misc.test:
Add NAME_CONST test.
mysql-test/t/rpl_name_const.test:
Test result.
sql/item.cc:
Re-set field's name if the name is autogenerated, that mean without aliase.
due to name_const substitution
Problem:
"In general, statements executed within a stored procedure
are written to the binary log using the same rules that
would apply were the statements to be executed in standalone
fashion. Some special care is taken when logging procedure
statements because statement execution within procedures
is not quite the same as in non-procedure context".
For example, each reference to a local variable in SP's
statements is replaced by NAME_CONST(var_name, var_value).
Queries like
"CREATE TABLE ... SELECT FUNC(local_var ..."
are logged as
"CREATE TABLE ... SELECT FUNC(NAME_CONST("local_var", var_value) ..."
that leads to differrent field names and
might result in "Incorrect column name" if var_value is long enough.
Fix: in 5.x we'll issue a warning in such a case.
In 6.0 we should get rid of NAME_CONST().
Note: this issue and change should be described in the documentation
("Binary Logging of Stored Programs").
mysql-test/r/binlog.result:
Fix for bug#35383: binlog playback and replication breaks
due to name_const substitution
- test result.
mysql-test/t/binlog.test:
Fix for bug#35383: binlog playback and replication breaks
due to name_const substitution
- test case.
sql/sp_head.cc:
Fix for bug#35383: binlog playback and replication breaks
due to name_const substitution
- set thd->query_name_consts if there's NAME_CONST()
substitution(s).
sql/sql_parse.cc:
Fix for bug#35383: binlog playback and replication breaks
due to name_const substitution
- issue a warning if there's NAME_CONST() substitution and
binary logging is on for "CREATE TABLE ... SELECT ...".
manual merge. also adds test specific to 5.1+
mysql-test/suite/rpl/r/rpl_temporary.result:
show that a non-privileged user trying to
kill system-threads no longer crashes the
server. test in 5.1+ only.
mysql-test/suite/rpl/t/rpl_temporary.test:
show that a non-privileged user trying to
kill system-threads no longer crashes the
server. test in 5.1+ only.
sql/sql_class.cc:
manual merge
sql/sql_class.h:
manual merge
sql/sql_parse.cc:
manual merge
Fine-tuning. Broke out comparison into method by
suggestion of Davi. Clarified comments. Reverting
test-case which I find too brittle; proper test
case in 5.1+.
(Pushing for Azundris)
We allow security-contexts with NULL users (for
system-threads and for unauthenticated users).
If a non-SUPER-user tried to KILL such a thread,
we tried to compare the user-fields to see whether
they owned that thread. Comparing against NULL was
not a good idea.
If KILLer does not have SUPER-privilege, we
specifically check whether both KILLer and KILLee
have a non-NULL user before testing for string-
equality. If either is NULL, we reject the KILL.
mysql-test/r/rpl_temporary.result:
Try to have a non-SUPER user KILL a system thread.
mysql-test/t/rpl_temporary.test:
Try to have a non-SUPER user KILL a system thread.
sql/sql_parse.cc:
Make sure security contexts of both KILLer *and*
KILLee are non-NULL before testing for string-equality!
The issue happened to be two-fold.
The table map event was recorded into binlog having
an incorrect size when number of columns exceeded 251.
The Row-based event had incorrect recording and restoring m_width member within
the same as above conditions.
Fixed with correcting m_data_size and m_width.
mysql-test/suite/rpl/r/rpl_row_wide_table.result:
the new test results.
mysql-test/suite/rpl/t/rpl_row_wide_table.test:
regression test for bug#42977.
sql/log_event.cc:
0. all buffers that used in net_store_length() are augmented with 1 for safety
to be able to contain the magic and the content of ulonglong as well;
1. Rows_log_event::get_data_size() yieled incorrect size |m_width/8| whereas
it should be m_width;
2. Table_map_log_event::Table_map_log_event yieled incorrect value for
`m_data_size' probably presuming 1-byte integer max for the column number;
sql/rpl_utility.h:
DBUG_PRINT_BITSET() macro is left 256-cols limited but has made safe and commented.
LOAD_FILE
LOAD_FILE is not safe to replicate in STATEMENT mode, because it
depends on a file (which is loaded on master and may not exist in
slave(s)). This leads to scenarios on which the slave replicates the
statement with 'load_file' and it will try to load the file from local
file system. Given that the file may not exist in the slave filesystem
the operation will not succeed (probably returning NULL), causing
master and slave(s) to diverge. However, when using MIXED mode
replication, this can be made to work, if the statement including
LOAD_FILE is marked as unsafe, triggering a switch to ROW mode,
meaning that the contents of the file are written to binlog as row
events. Consequently, the contents from the file in the master will
reach the slave via the binlog.
This patch addresses this bug by marking the load_file function as
unsafe. When in mixed mode and when LOAD_FILE is issued, there will be
a switch to row mode. Furthermore, when in statement mode, the
LOAD_FILE will raise a warning that the statement is unsafe in that
mode.
mysql-test/extra/rpl_tests/rpl_loadfile.test:
Extra file that is "sourced" on both rpl_loadfile and rpl_stm_loadfile
test files.
mysql-test/suite/rpl/r/rpl_loadfile.result:
Updated with the results from the test case added to this file.
mysql-test/suite/rpl/r/rpl_stm_loadfile.result:
Result file for rpl_loadfile test split with the warnings in statement
mode.
mysql-test/suite/rpl/t/rpl_loadfile.test:
After splitting the original rpl_loadfile file, this one is only
required to be executed in mixed or row format.
Appended the test for 39701 to this file.
mysql-test/suite/rpl/t/rpl_stm_loadfile.test:
Split the original rpl_loadfile test because load_file now raises
a warning when in statement mode. The goal of this split is
two-fold: i) make the test case more resilient; ii) assert that
warnings are indeed raised when in statement mode.
sql/item_create.cc:
Added the set_stmt_unsafe call to lex.
When do 'insert delayed' operation, the time_zone info doesn't be keeped in the row info.
So when we do insert sometime later, time_zone didn't write into binlog.
This will cause wrong result for timestamp column in slave.
Our solution is that adding time_zone info with the delayed-row and
restoring time_zone from row-info when execute that row in the furture by another thread.
So we can write correct time_zone info into binlog and got correct result in slave.
mysql-test/r/rpl_timezone.result:
Test result
mysql-test/t/rpl_timezone.test:
Add test for bug#41719
sql/sql_insert.cc:
Add time_zone info in the delayed-row and restore time_zone when execute the row in the furture by another thread.
functions
Unknown timezone specifications are properly rejected
by the server, but are copied into tz_storage before
rejection, and hence is retained until end of server
life. With sufficiently large bogus timezone specs,
it is easy to exhaust system memory.
Allocation of memory for a copy of the timezone
name is delayed until after verification of validity,
at the cost of a memcpy of the timezone info. This
only happens once, future lookups will hit the cached
structure.
Don't throw an error after checking the first and the second arguments.
Continue with checking the third and higher arguments and if some of
them is stronger according to coercibility rules,
then this argument's collation is set as result collation.
mysql-test/r/ctype_collate.result:
test result
mysql-test/t/ctype_collate.test:
test case
sql/item.cc:
Don't throw an error after checking the first and the second arguments.
Continue with checking the third and higher arguments and if some of
them is stronger according to coercibility rules,
then this argument's collation is set as result collation.
mysql.procs_priv table itself does not get replicated.
Inserting routine privilege record into mysql.procs_priv table
is triggered by creating function/procedure statements
according to current user's privileges.
Because the current user of SQL thread has GLOBAL_ACL,
which doesn't need any check mysql.procs_priv privilege
when create/alter/execute routines.
Corresponding GLOBAL_ACL privilege user
doesn't insert routine privilege record into
mysql.procs_priv when creating a routine.
Fixed by switching the current user of SQL thread to definer user if
the definer user exists on slave.
That populates procs_priv, otherwise to keep the SQL thread
user and procs_priv remains unchanged.
mysql-test/suite/rpl/r/rpl_do_grant.result:
Test case result for routine privilege when definer user exist or not on slave
mysql-test/suite/rpl/t/rpl_do_grant.test:
Test case result for routine privilege when definer user exist or not on slave
sql/sql_parse.cc:
Switch current user of SQL thread to definer user if the definer user
existes on slave when checking whether the routine privilege is
needed to insert mysql.procs_priv table or not.
Compiling with debug and assigning an invalid directory to --slave-load-tmpdir
was crashing the slave due to the following assertion DBUG_ASSERT(! is_set() ||
can_overwrite_status). This assertion assumes that a thread can change its
state once (i.e. ok,error, etc) before aborting, cleaning/resuming or completing
its execution unless the overwrite flag (i.e. can_overwrite_status) is true.
The Append_block_log_event::do_apply_event which is responsible for creating
temporary file(s) was not cleaning the thread state. Thus a failure while
trying to create a file in an invalid temporary directory was causing the crash.
To fix the problem we check if the temporary directory is valid before starting
the SQL Thread and reset the thread state before creating a file in
Append_block_log_event::do_apply_event.
become negative
- merged the fix to 5.1
- extended to cover I_S.PROCESSLIST.TIME
- Changed the column type of I_S.PROCESSLIST.TIME from LOGNLONG
UNSIGNED
to LONG (to match the SHOW PROCESSLIST type)
- Added a test case
- Fix valgrind warning on attempt to run a "SET optimizer_switch=number" statement.
Need to call c_ptr_safe() as strings returned by non-string items are not
necessarily null-terminated.
The problem is issued because we set wrong start position and stop position of query string into binlog.
That two values are stored as part of head info of query string.
When we parse binlog, we first get position values then get the query string according position values.
But seems that two values are not calculated correctly after the parse of Yacc.
We don't want to touch so much of yacc because it may influence other codes.
So just add one space after 'INTO' key word when parsing.
This can easily resolve the problem.
mysql-test/suite/rpl/r/rpl_loaddatalocal.result:
Test result
mysql-test/suite/rpl/t/rpl_loaddatalocal.test:
Test case
sql/log_event.cc:
Add space after 'INTO'.
select where .. (col=col and col=col) or ... (false expression)
Problem: optimizer didn't take into account a singular case
when we eliminated all the predicates at the AND level of WHERE.
That may lead to wrong results.
Fix: replace (a=a AND a=a...) with TRUE if we eliminated all the
predicates.
mysql-test/r/select.result:
Fix for bug #42957: no results from
select where .. (col=col and col=col) or ... (false expression)
- test result.
mysql-test/t/select.test:
Fix for bug #42957: no results from
select where .. (col=col and col=col) or ... (false expression)
- test case.
sql/sql_select.cc:
Fix for bug #42957: no results from
select where .. (col=col and col=col) or ... (false expression)
- replacing equality predicates by multiple equality items check
if we eliminate all the predicates at the AND level and
replace them with TRUE if so.
