This fix affects the test suite only.
Before this fix, performance schema tests dml_*.test could
fail with spurious failure, depending on the table content.
This fix simplifies the SELECT tests in the dml_*.test scripts,
to only verify that the SELECT operation passed the security checks
and succeeded, which was the original intent of the test.
Usage of
--replace_column 1 # 2 # 3 # 4 # ...
to discard the test output was replaced by a simpler and more maintainable
--disable_result_log
which also work for empty tables.
when generating new name.
If find_uniq_filename returns an error, then this error is not
being propagated upwards, and execution does not report error to
the user (although a entry in the error log is generated).
Additionally, some more errors were ignored in new_file_impl:
- when writing the rotate event
- when reopening the index and binary log file
This patch addresses this by propagating the error up in the
execution stack. Furthermore, when rotation of the binary log
fails, an incident event is written, because there may be a
chance that some changes for a given statement, were not properly
logged. For example, in SBR, LOAD DATA INFILE statement requires
more than one event to be logged, should rotation fail while
logging part of the LOAD DATA events, then the logged data would
become inconsistent with the data in the storage engine.
The problem was due to a misuse of GCC asm constraints used to
implement a atomic load. On x86_64, the load was implemented
as a cmpxchg which implicitly uses the eax register as a
source and destination operand, yet the dummy value used for
comparison wasn't being properly loaded into eax (and other
problems).
The core problem is that cmpxchg is unnecessary as a load
on x86_64 as there are other simpler instructions such
as xadd. Even though, such instructions are only used to
have a memory barrier as load and stores are atomic by
definition. Hence, the solution is to explicitly issue the
required CPU and compiler barriers.
InnoDB does not attempt to handle lower_case_table_names == 2 when looking
up foreign table names and referenced table name. It turned that server
variable into a boolean and ignored the possibility of it being '2'.
The setting lower_case_table_names == 2 means that it should be stored and
displayed in mixed case as given, but compared internally in lower case.
Normally the server deals with this since it stores table names. But
InnoDB stores referential constraints for the server, so it needs to keep
track of both lower case and given names.
This solution creates two table name pointers for each foreign and referenced
table name. One to display the name, and one to look it up. Both pointers
point to the same allocated string unless this setting is 2. So the overhead
added is not too much.
Two functions are created in dict0mem.c to populate the ..._lookup versions
of these pointers. Both dict_mem_foreign_table_name_lookup_set() and
dict_mem_referenced_table_name_lookup_set() are called 5 times each.
The problem was that mysql_upgrade failed because DROP DATABASE
refused to drop the 'performance_schema' database when the
mysql.proc table definition was made temporarily invalid
by dump import.
This patch fixes the problem by adding the error resulting
from opening a damaged mysq.proc table (ER_CANNOT_LOAD_FROM_TABLE),
to the list of errors DROP DATABASE will ignore when trying
to lock stored procedures and functions before deletion.
This problem was a regression introduced by the patch for
Bug#57663.
Test case added to sp-destruct.test.
the DROP statement ..."
Problem: When using temporary tables and closing a session, an
implicit DROP TEMPORARY TABLE IF EXISTS is written to the binary
log (while cleaning up the context of the session THD - see:
sql_class.cc:THD::cleanup which calls close_temporary_tables).
close_temporary_tables, first checks if the binary log is opened
and then proceeds to creating the DROP statements. Then, such
statements, are written to the binary log through
MYSQL_BIN_LOG::write(Log_event *). Inside, there is another check
if the binary log is opened and if not an error is returned. This
is where the faulty behavior is triggered. Given that the test
case replays a binary log, with temp tables statements, and right
after it issues RESET MASTER, there is a chance that is_open will
report false (when the mysql session is closed and the temporary
tables are written).
is_open may return false, because MYSQL_BIN_LOG::reset_logs is
not setting the correct flag (LOG_CLOSE_TO_BE_OPENED), on the
MYSQL_LOG_BIN::log_state (instead it sets just the
LOG_CLOSE_INDEX flag, leaving the log_state to
LOG_CLOSED). Thence, when writing the DROP statement as part of
the THD::cleanup, the thread could get a return value of false
for is_open - inside MYSQL_BIN_LOG::write, ultimately reporting
that it can't write the event to the binary log.
Fix: We fix this by adding the correct flag, missing in the
second close.
Code cleanup after changes for Bug 56628. The general approach for
InnoDB is to make a reference to each enum value whenever it is used in a
switch statement. In addition, no default case should be used for switch
statements on enum types. This assures that if there is ever any change
in the enum values, the switch will need to change to reflect it since a
compiler warning will occur. In this case, the enum row_type is declared
in handler.h and could be changed for another storage engine. If so, a
warning will occur in the InnoDB build.
Other changes;
* This patch uses 2 macros to help consolidate warning messages that
need to occur twice in the single switch for row_format.
* Using row_format as the variable name to distinguish it from the enum
type.
* Function declaration format correction.
Code cleanup after changes for Bug 56628. The general approach for
InnoDB is to make a reference to each enum value whenever it is used in a
switch statement. In addition, no default case should be used for switch
statements on enum types. This assures that if there is ever any change
in the enum values, the switch will need to change to reflect it since a
compiler warning will occur. In this case, the enum row_type is declared
in handler.h and could be changed for another storage engine. If so, a
warning will occur in the InnoDB build.
Other changes;
* This patch uses 2 macros to help consolidate warning messages that
need to occur twice in the single switch for row_format.
* Using row_format as the variable name to distinguish it from the enum
type.
* Function declaration format correction.
Fix a race condition in srv_master_thread(). We need to acquire the kernel
mutex before calling srv_table_reserve_slot(). Add a mutex_own() assertion
in srv_table_reserve_slot().
Do not print pointer to the 5.1 documentation from within MySQL 5.5.
Instead of hardcoding the MySQL version, use the MAJOR_VERSION and
MINOR_VERSION CMake variables defined at top-level.
It is not necessary to support INSERT DELAYED for a single value insert,
while we do not support that for multi-values insert when binlog is
enabled in SBR.
The lock_type is upgrade to TL_WRITE from TL_WRITE_DELAYED for
INSERT DELAYED for single value insert as multi-values insert
did when binlog is enabled. Then it's safe. And binlog it as
INSERT without DELAYED.
When using BINLOG statement to execute rows log events, session variables
foreign_key_checks and unique_checks are changed temporarily. As each rows
log event has their own special session environment and its own
foreign_key_checks and unique_checks can be different from current session
which executing the BINLOG statement. But these variables are not restored
correctly after BINLOG statement. This problem will cause that the following
statements fail or generate unexpected data.
In this patch, code is added to backup and restore these two variables.
So BINLOG statement will not affect current session's variables again.
win x86 debug_max
The windows MTR run exhibited a different test execution
ordering (due to the fact that in these platforms MTR is invoked
with --parallel > 1). This uncovered a bug in the aforementioned
test case, which is triggered by the following conditions:
1. server is not restarted between two different tests;
2. the test before binlog.binlog_row_failure_mixing_engines
issues flush logs;
3. binlog.binlog_row_failure_mixing_engines uses binlog
positions to limit the output of show_binlog_events;
4. binlog.binlog_row_failure_mixing_engines does not state which
binlog file to use, thence it uses a wrong binlog file with
the correct position.
There are two possible fixes: 1. make sure that the test start
from a clean slate - binlog wise; 2. in addition to the position,
also state the binary log file before sourcing
show_binlog_events.inc .
We go for fix#1, ie, deploy a RESET MASTER before the test is
actually started.
The problem is that the logic which checks if a pointer is
valid relies on a poor heuristic based on the start and end
addresses of the data segment and heap.
Apart from miscalculating the heap bounds, this approach also
suffers from the fact that memory can come from places other
than the heap. See Bug#58528 for a more detailed explanation.
On Linux, the solution is to access the process's memory
through /proc/self/task/<tid>/mem, which allows for retrieving
the contents of pages within the virtual address space of
the calling process. If a address range is not mapped, a
input/output error is returned.
