Bug#46539 Various crashes on INSERT IGNORE SELECT + SELECT FOR UPDATE.
If a transaction was rolled back inside InnoDB due to a deadlock
or lock wait timeout, and the statement had IGNORE clause,
the server could crash at the end of the statement or on shutdown.
This was caused by the error handling infrastructure's attempt to
ignore a non-ignorable error.
When a transaction rollback request is raised, switch off
current_select->no_error flag, so that the following error
won't be ignored.
Instead, we could add !thd->is_fatal_sub_stmt_error to
my_message_sql(), but since in write_record() we switch
off no_error, the same approach is used in
thd_mark_transaction_to_rollback().
@todo: call thd_mark_transaction_to_rollback() from
handler::print_error(), then we can easily make sure
that the error reported by print_error is not ignored.
mysql-test/r/innodb_lock_wait_timeout_1.result:
Update results (Bug#46539).
mysql-test/t/innodb_lock_wait_timeout_1.test:
Add a test case for Bug#46539
sql/sql_class.cc:
When a transaction rollback request is raised, switch of
current_select->no_error flag, so that the following error
won't be ignored.
"What do you mean, there's a bug? There isn't even code!"
There was some token code for plug-in variables of the SET type,
but clearly this never worked, or was subject to massive bit rot
since. Bug-fixes ... fail-safes ... tests -- fais au mieux, mon chou!
mysys/my_getopt.c:
SETs set-up should set up a default value, but no min/max bounding.
mysys/typelib.c:
fail-safe requested by serg: don't try to skip separator when we're
already at end of string.
sql/sql_plugin.cc:
check_func_set:
Initialize error_len as find_set() will only update it on error,
and we're using the value to see whether an error has occurred (!= 0),
so we'd better not have a random val in there.
value_ptr:
There's no guarantee we're handed string lengths, so play it safe!
Use prepared string lengths where possible for minimum speed gain,
otherwise determine on the fly!
Problem 1:
column_priv_hash uses utf8_general_ci collation
for the key comparison. The key consists of user name,
db name and table name. Thus user with privileges on table t1
is able to perform the same operation on T1
(the similar situation with user name & db name, see acl_cache).
So collation which is used for column_priv_hash and acl_cache
should be case sensitive.
The fix:
replace system_charset_info with my_charset_utf8_bin for
column_priv_hash and acl_cache
Problem 2:
The same situation with proc_priv_hash, func_priv_hash,
the only difference is that Routine name is case insensitive.
So the fix is to use my_charset_utf8_bin for
proc_priv_hash & func_priv_hash and convert routine name into lower
case before writing the element into the hash and
before looking up the key.
Additional fix: mysql.procs_priv Routine_name field collation
is changed to utf8_general_ci.
It's necessary for REVOKE command
(to find a field by routine hash element values).
Note:
It's safe for lower-case-table-names mode too because
db name & table name are converted into lower case
(see GRANT_NAME::GRANT_NAME).
mysql-test/include/have_case_insensitive_fs.inc:
test case
mysql-test/r/case_insensitive_fs.require:
test case
mysql-test/r/grant_lowercase_fs.result:
test result
mysql-test/r/lowercase_fs_off.result:
test result
mysql-test/r/ps_grant.result:
test result
mysql-test/r/system_mysql_db.result:
changed Routine_name field collation to case insensitive
mysql-test/t/grant_lowercase_fs.test:
test case
mysql-test/t/lowercase_fs_off.test:
test case
scripts/mysql_system_tables.sql:
changed Routine_name field collation to case insensitive
scripts/mysql_system_tables_fix.sql:
changed Routine_name field collation to case insensitive
sql/sql_acl.cc:
Problem 1:
column_priv_hash uses utf8_general_ci collation
for the key comparison. The key consists of user name,
db name and table name. Thus user with privileges on table t1
is able to perform the same operation on T1
(the similar situation with user name & db name, see acl_cache).
So collation which is used for column_priv_hash and acl_cache
should be case sensitive.
The fix:
replace system_charset_info with my_charset_utf8_bin for
column_priv_hash and acl_cache
Problem 2:
The same situation with proc_priv_hash, func_priv_hash,
the only difference is that Routine name is case insensitive.
So the fix is to use my_charset_utf8_bin for
proc_priv_hash & func_priv_hash and convert routine name into lower
case before writing the element into the hash and
before looking up the key.
Additional fix: mysql.procs_priv Routine_name field collation
is changed to utf8_general_ci.
It's necessary for REVOKE command
(to find a field by routine hash element values).
Note:
It's safe for lower-case-table-names mode too because
db name & table name are converted into lower case
(see GRANT_NAME::GRANT_NAME).
If the first argument to GeomFromWKB function is a geometry
field then the function just returns its value.
However in doing so it's not preserving first argument's
null_value flag and this causes unexpected null value to
be returned to the calling function.
Fixed by updating the null_value of the GeomFromWKB function
in such cases (and all other cases that return a NULL e.g.
because of not enough memory for the return buffer).
Problem: involving a spatial index for "non-spatial" queries
(that don't containt MBRXXX() functions) may lead to failed assert.
Fix: don't use spatial indexes in such cases.
mysql-test/r/gis-rtree.result:
Fix for bug#48258: Assertion failed when using a spatial index
- test result.
mysql-test/t/gis-rtree.test:
Fix for bug#48258: Assertion failed when using a spatial index
- test case.
sql/opt_range.cc:
Fix for bug#48258: Assertion failed when using a spatial index
- allow only spatial functions (MBRXXX) for itMBR keyparts.
line 138 when forcing a spatial index
Problem: "Spatial indexes can be involved in the search
for queries that use a function such as MBRContains()
or MBRWithin() in the WHERE clause".
Using spatial indexes for JOINs with =, <=> etc.
predicates is incorrect.
Fix: disable spatial indexes for such queries.
mysql-test/r/select.result:
Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c,
line 138 when forcing a spatial index
- test result.
mysql-test/t/select.test:
Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c,
line 138 when forcing a spatial index
- test case.
sql/sql_select.cc:
Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c,
line 138 when forcing a spatial index
- disable spatial indexes for queries which use
non-spatial conditions (e.g. NATURAL JOINs).
grants are reapplied.
After renaming a user and trying to re-apply grants results in additional
grants.
This is because we use username as part of the key for GRANT_TABLE structure.
When the user is renamed, we only change the username stored and the hash key
still contains the old user name and this results in the extra privileges
Fixed by rebuilding the hash key and updating the column_priv_hash structure
when the user is renamed
mysql-test/r/grant3.result:
Bug #41597 - After rename of user, there are additional grants when
grants are reapplied.
Testcase for BUG#41597
mysql-test/t/grant3.test:
Bug #41597 - After rename of user, there are additional grants when
grants are reapplied.
Testcase for BUG#41597
sql/sql_acl.cc:
Bug #41597 - After rename of user, there are additional grants when
grants are reapplied.
Fixed handle_grant_struct() to update the hash key when the user is renamed.
Added to set_user_details() method to GRANT_NAME class
If a thread is killed in the server, we throw "shutdown" only if one is actually in
progress; otherwise, we throw "query interrupted".
Control-C in the mysql command-line client is "incremental" now.
First Control-C sends KILL QUERY (when connected to 5.0+ server, otherwise, see next)
Next Control-C sends KILL CONNECTION
Next Control-C aborts client.
As the first two steps only pertain to an existing query,
Control-C will abort the client right away if no query is running.
client will give more detailed/consistent feedback on Control-C now.
client/mysql.cc:
Extends Control-C handling; enhances up feedback to user.
On 5.0+ servers, we try to be nice and send KILL QUERY first
if Control-C is pressed in the command-line client, but if
that doesn't work, we now give the user the opportunity to
send KILL CONNECTION with another Control-C (and to kill the
client with another Control-C if that somehow doesn't work
either).
mysql-test/t/flush_read_lock_kill.test:
we're getting correct "thread killed" rather than
"in shutdown" error now
mysql-test/t/kill.test:
we're getting correct "thread killed" rather than
"in shutdown" error now
mysql-test/t/rpl000001.test:
we're getting correct "thread killed" rather than
"in shutdown" error now
mysql-test/t/rpl_error_ignored_table.test:
we're getting correct "thread killed" rather than
"in shutdown" error now
sql/records.cc:
make error messages on KILL uniform for rr_*()
by folding that handling into rr_handle_error()
sql/sql_class.h:
Only throw "shutdown" when we have one flagged as being in progress;
otherwise, throw "query interrupted" as it's likely to be "KILL CONNECTION"
or related.
UPDATE + VIEW + SP + MERGE + ALTER
When cleaning up the stored procedure's internal
structures the flag to ignore the errors for
INSERT/UPDATE IGNORE was not cleaned up.
As a result error ignoring was on during name
resolution. And this is an abnormal situation : the
SELECT_LEX flag can be on only during query execution.
Fixed by correctly cleaning up the SELECT_LEX flag
when reusing the SELECT_LEX in a second execution.
SP variables
A function call may end without throwing an error or without setting
the return value. This can happen when e.g. an error occurs while
calculating the return value.
Fixed by setting the value to NULL when error occurs during evaluation
of an expression.
This assertion would occur if UPDATE was used to update multiple
tables containing an AUTO_INCREMENT column and if the inserted
row had a user-supplied value for that column. The assertion
could then be triggered by the next statement.
The problem was only noticeable on debug builds of the server.
The cause of the problem was that the code for multi update did
not properly reset the TABLE->auto_increment_if_null flag after update.
The flag is used to indicate that a non-null value of an auto_increment field
has been provided by the user or retrieved from a current record.
Open_tables() contains an assertion that tests this flag, and this
was triggered in this case by ALTER TABLE.
This patch fixes the problem by resetting the auto_increment_if_null
field to FALSE once a row has been updated.
This bug is similar to Bug#47274, but for multi update rather
than INSERT DELAYED.
Test case added to update.test.
file
Issuing 'FLUSH LOGS' does not close and reopen indexfile.
Instead a SEEK_SET is performed.
This patch makes index file to be closed and reopened whenever a
rotation happens (FLUSH LOGS is issued or binary log exceeds
maximum configured size).
mysql-test/suite/binlog/r/binlog_delete_and_flush_index.result:
Result file.
mysql-test/suite/binlog/t/binlog_delete_and_flush_index.test:
Test case.
sql/log.cc:
Added LOG_CLOSE_INDEX flag when calling MYSQL_BIN_LOG::close
from within MYSQL_BIN_LOG::new_file_impl (which should just be
called whenever a rotation is to happen - FLUSH LOGS issued or
binlog size exceeds the maximum configured).
Adding @@session and @@global prefixes to a
declared variable in a stored procedure the server
would lead to a crash.
The reason was that during the parsing of the
syntactic rule 'option_value' an uninitialized
set_var object was pushed to the parameter stack
of the SET statement. The parent rule
'option_type_value' interpreted the existence of
variables on the parameter stack as an assignment
and wrapped it in a sp_instr_set object.
As the procedure later was executed an attempt
was made to run the method 'check()' on an
uninitialized member object (NULL value) belonging
to the previously created but uninitialized object.
sql/sql_yacc.yy:
* Assign the option_type at once since it is needed by the next
parsing rule (internal_variable_name)
* Rearranged the if statement to reduce negations and gain more
clarity of code.
* Added check for option_type to better detect if current
variable is a SP local variable or a system variable.
Problem: using null microsecond part in a WHERE condition
(e.g. WHERE date_time_field <= "YYYY-MM-DD HH:MM:SS.0000")
may lead to wrong results due to improper DATETIMEs
comparison in some cases.
Fix: comparing DATETIMEs as strings we must trim trailing 0's
in such cases.
mysql-test/r/innodb_mysql.result:
Fix for bug#47963: Wrong results when index is used
- test result.
mysql-test/t/innodb_mysql.test:
Fix for bug#47963: Wrong results when index is used
- test case.
sql/item.cc:
Fix for bug#47963: Wrong results when index is used
- comparing DATETIMEs as strings we must trim trailing 0's in the
microsecond part to ensure
'YYYY-MM-DD HH:MM:SS.000' == 'YYYY-MM-DD HH:MM:SS'
The problem was in incorrect handling of predicates involving
NULL as a constant value by the range optimizer.
For example, when creating a SEL_ARG node from a condition of
the form "field < const" (which would normally result in the
"NULL < field < const" SEL_ARG), the special case when "const"
is NULL was not taken into account, so "NULL < field < NULL"
was produced for the "field < NULL" condition.
As a result, SEL_ARG structures of this form could not be
further optimized which in turn could lead to incorrectly
constructed SEL_ARG trees. In particular, code assuming SEL_ARG
structures to always form a sequence of ordered disjoint
intervals could enter an infinite loop under some
circumstances.
Fixed by changing get_mm_leaf() so that for any sargable
predicate except "<=>" involving NULL as a constant, "empty"
SEL_ARG is returned, since such a predicate is always false.
mysql-test/r/partition_pruning.result:
Fixed a broken test case.
mysql-test/r/range.result:
Added a test case for bug #47123.
mysql-test/r/subselect.result:
Fixed a broken test cases.
mysql-test/t/range.test:
Added a test case for bug #47123.
sql/opt_range.cc:
Fixed get_mm_leaf() so that for any sargable
predicate except "<=>" involving NULL as a constant, "empty"
SEL_ARG is returned, since such a predicate is always false.
view that has Group By
When SELECT'ing from a view that mentions another,
materialized, view, access was being denied. The issue was
resolved by lifting a special case which avoided such access
checking in check_single_table_access. In the past, this was
necessary since if such a check were performed, the error
message would be downgraded to a warning in the case of SHOW
CREATE VIEW. The downgrading of errors was meant to handle
only that scenario, but could not distinguish the two as it
read only the error messages.
The special case was needed in the fix of bug no 36086.
Before that, views were confused with derived tables.
After bug no 35996 was fixed, the manipulation of errors
during SHOW CREATE VIEW execution is not dependent on the
actual error messages in the queue, it rather looks at the
actual cause of the error and takes appropriate
action. Hence the aforementioned special case is now
superfluous and the bug is fixed.
mysql-test/r/view_grant.result:
Bug#46019: Test result.
mysql-test/t/view_grant.test:
Bug#46019: Test case.
sql/sql_parse.cc:
Bug#46019: fix.
Implemented the server infrastructure for the fix:
1. Added a function LEX_STRING *thd_query_string(THD) to return
a LEX_STRING structure instead of char *.
This is the function that must be called in innodb instead of
thd_query()
2. Did some encapsulation in THD : aggregated thd_query and
thd_query_length into a LEX_STRING and made accessor and mutator
methods for easy code updating.
3. Updated the server code to use the new methods where applicable.
Temporary tables may set join->group to 0 even though there is
grouping. Also need to test if sum_func_count>0 when JOIN::exec()
decides whether to present results in a grouped manner.
sql/sql_select.cc:
Temporary tables may set join->group to 0 even though there is
grouping. Also need to test if sum_func_count>0 when JOIN::exec()
decides whether to present results in a grouped manner.
columns without where/group
Simple SELECT with implicit grouping used to return many rows if
the query was ordered by the aggregated column in the SELECT
list. This was incorrect because queries with implicit grouping
should only return a single record.
The problem was that when JOIN:exec() decided if execution needed
to handle grouping, it was assumed that sum_func_count==0 meant
that there were no aggregate functions in the query. This
assumption was not correct in JOIN::exec() because the aggregate
functions might have been optimized away during JOIN::optimize().
The reason why queries without ordering behaved correctly was
that sum_func_count is only recalculated if the optimizer chooses
to use temporary tables (which it does in the ordered case).
Hence, non-ordered queries were correctly treated as grouped.
The fix for this bug was to remove the assumption that
sum_func_count==0 means that there is no need for grouping. This
was done by introducing variable "bool implicit_grouping" in the
JOIN object.
mysql-test/r/func_group.result:
Add test for BUG#47280
mysql-test/t/func_group.test:
Add test for BUG#47280
sql/opt_sum.cc:
Improve comment for opt_sum_query()
sql/sql_class.h:
Add comment for variables in TMP_TABLE_PARAM
sql/sql_select.cc:
Introduce and use variable implicit_grouping instead of (!group_list && sum_func_count) in places that need to test if grouping is required. Also added comments for: optimization of aggregate fields for implicitly grouped queries (JOIN::optimize) and choice of end_select method (JOIN::execute)
sql/sql_select.h:
Add variable implicit_grouping, which will be TRUE for queries that contain aggregate functions but no GROUP BY clause. Also added comment to sort_and_group variable.
The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
id stored inside the events of the BINLOG statement rather than the id of the running
server.
Fix by rearranging code a bit so that only relevant parts of the code are executed by
the BINLOG statement, and the server_id of the server executing the statements will
not be overrided by the server_id stored in the 'format description BINLOG statement'.
mysql-test/extra/binlog_tests/binlog.test:
Added test to verify if the server_id stored in the 'format
description BINLOG statement' will override the server_id
of the server executing the statements.
mysql-test/suite/binlog/r/binlog_row_binlog.result:
Test result for bug#46640
mysql-test/suite/binlog/r/binlog_stm_binlog.result:
Test result for bug#46640
sql/log_event.cc:
Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
makes more sense, and is needed as update_pos() is no longer called when executing
BINLOG statements.
Moved setting of rli->relay_log.description_event_for_exec from
Format_description_log_event::do_update_pos() to
Format_description_log_event::do_apply_event()
sql/log_event_old.cc:
Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
makes more sense, and is needed as update_pos() is no longer called when executing
BINLOG statements.
sql/slave.cc:
The skip flag is no longer needed, as the code path for BINLOG statement has been
cleaned up.
sql/sql_binlog.cc:
Don't invoke the update_pos() code path for the BINLOG statement, as it contains code
that is redundant and/or harmful (especially setting thd->server_id).
The problem was in incorrect handling of predicates involving
NULL as a constant value by the range optimizer.
For example, when creating a SEL_ARG node from a condition of
the form "field < const" (which would normally result in the
"NULL < field < const" SEL_ARG), the special case when "const"
is NULL was not taken into account, so "NULL < field < NULL"
was produced for the "field < NULL" condition.
As a result, SEL_ARG structures of this form could not be
further optimized which in turn could lead to incorrectly
constructed SEL_ARG trees. In particular, code assuming SEL_ARG
structures to always form a sequence of ordered disjoint
intervals could enter an infinite loop under some
circumstances.
Fixed by changing get_mm_leaf() so that for any sargable
predicate except "<=>" involving NULL as a constant, "empty"
SEL_ARG is returned, since such a predicate is always false.
mysql-test/r/range.result:
Added a test case for bug #47123.
mysql-test/t/range.test:
Added a test case for bug #47123.
sql/opt_range.cc:
Fixed get_mm_leaf() so that for any sargable
predicate except "<=>" involving NULL as a constant, "empty"
SEL_ARG is returned, since such a predicate is always false.
Problem: using null microsecond part (e.g. "YYYY-MM-DD HH:MM:SS.0000")
in a WHERE condition may lead to wrong results due to improper
DATETIMEs comparison in some cases.
Fix: as we compare DATETIMEs as strings we must trim trailing 0's
in such cases.
mysql-test/r/innodb_mysql.result:
Fix for bug#47963: Wrong results when index is used
- test result.
mysql-test/t/innodb_mysql.test:
Fix for bug#47963: Wrong results when index is used
- test case.
sql/item.cc:
Fix for bug#47963: Wrong results when index is used
- comparing DATETIMEs trim trailing 0's in the
microsecond part.
removed if server_id changes
When MySQL crashes (or a snapshot is taken which simulates
a crash), then it is possible that internal XA
transactions (used to sync the binary log and InnoDB)
can be left in a PREPARED state, whereas they should be
rolled back. This is done when the server_id changes
before the restart occurs.
This patch releases he restriction that the server_id
should be consistent if the XID is to be considerred
valid. The rollback phase should then be able to
clean up all pending XA transactions.
We set up DATE and TIMESTAMP differently in field-creation than we
did in field-MD creation (for CREATE). Admirably, ALTER TABLE
detected this and didn't damage any data, but it did initiate a
full copy/conversion, which we don't really need to do.
Now we describe Field and Create_field the same for those types.
As a result, ALTER TABLE that only changes meta-data (like a
field's name) no longer forces a data-copy when there needn't
be one.
mysql-test/r/alter_table.result:
0 rows should be affected when a meta-data change is enough ALTER TABLE.
mysql-test/t/alter_table.test:
add test-case: show that we don't do a full data-copy on ALTER TABLE
when we don't need to.
sql/field.cc:
Remove Field_str::compare_str_field_flags() (now in Field/Create_field as
field_flags_are_binary().
Correct some field-lengths!
sql/field.h:
Clean-up: use defined constants rather than numeric literals for certain
field-lengths.
Add enquiry-functions binaryp() to classes Field and Create_field.
This replaces field.cc's Field_str::compare_str_field_flags().
