- Fixed some issues with partitions and connection_string, which also fixed lp:716890 "Pre- and post-recovery crash in Aria"
- Fixed wrong assert in Aria
Now need to merge with latest xtradb before pushing
sql/ha_partition.cc:
Ensure that m_ordered_rec_buffer is not freed before close.
sql/mysqld.cc:
Changed to use opt_stack_trace instead of opt_pstack.
Removed references to pstack
sql/partition_element.h:
Ensure that connect_string is initialized
storage/maria/ma_key_recover.c:
Fixed wrong assert
Problem: Warnings for truncated data were generated on hosts with
long host names because @@hostname was inserted into a CHAR(40) column.
Fix: Change CHAR(40) to TEXT.
On Unix systems TZ can be set to change the time zone for specific processes only.
But on Windows this does not fully work. It changes some aspects of time zones
in the system but not others (notably localtime() vs. file system time stamps).
This causes test failures in Windows in certain time zones (but not all),
where PURGE BEFORE DATE statements get the wrong files when TZ is set to
+03:00 by default.
Fix by only setting TZ in the small number of tests that really need it, and leave
it untouched in the rest.
Thanks to Alex Budovski for helping with this.
mysql-test/include/ps_conv.inc:
Explicitly set TIME_ZONE, as mysql-test-run.pl now does not set it.
mysql-test/mysql-test-run.pl:
Do not set TZ by default, as it causes problems on Windows.
mysql-test/suite/binlog/r/binlog_unsafe.result:
Explicitly set TIME_ZONE, as mysql-test-run.pl now does not set it.
mysql-test/suite/binlog/t/binlog_unsafe.test:
Explicitly set TIME_ZONE, as mysql-test-run.pl now does not set it.
mysql-test/suite/rpl/r/rpl_mixed_ddl_dml.result:
Explicitly set TIME_ZONE, as mysql-test-run.pl now does not set it.
mysql-test/suite/rpl/t/rpl_mixed_ddl_dml.test:
Explicitly set TIME_ZONE, as mysql-test-run.pl now does not set it.
mysql-test/t/mysqlbinlog2-master.opt:
mysql-test-run.pl no longer sets TZ by default, so set it explicitly for this particular test.
Problem: When RAND() is binlogged in statement mode, the seed is
binlogged too, so the replication slave generates the same
sequence of random numbers. This makes replication work in many
cases, but not in all cases: the order of rows is not guaranteed
for, e.g., UPDATE or INSERT...SELECT statements, so the row data
will be different if master and slave retrieve the rows in
different orders.
Fix: Mark RAND() as unsafe. It will generate a warning if
binlog_format=STATEMENT and switch to row-logging if
binlog_format=ROW.
mysql-test/extra/rpl_tests/rpl_row_func003.test:
updated test case to ignore new warnings
mysql-test/suite/binlog/r/binlog_unsafe.result:
updated result file
mysql-test/suite/binlog/t/binlog_unsafe.test:
Added test for RAND().
Also clarified some old comments.
mysql-test/suite/rpl/r/rpl_misc_functions.result:
updated result file
mysql-test/suite/rpl/r/rpl_nondeterministic_functions.result:
updated test case to ignore new warnings
mysql-test/suite/rpl/r/rpl_optimize.result:
updated result file
mysql-test/suite/rpl/r/rpl_row_func003.result:
updated result file
mysql-test/suite/rpl/t/rpl_misc_functions.test:
updated test case to ignore new warnings
mysql-test/suite/rpl/t/rpl_nondeterministic_functions.test:
updated test case to ignore new warnings
mysql-test/suite/rpl/t/rpl_optimize.test:
updated test case to ignore new warnings
mysql-test/suite/rpl/t/rpl_trigger.test:
updated test case to ignore new warnings
mysql-test/suite/rpl_ndb/r/rpl_ndb_func003.result:
updated result file
sql/item_create.cc:
Mark RAND() unsafe.
Problem: Some system functions that could return different values on
master and slave were not marked unsafe. In particular:
GET_LOCK
IS_FREE_LOCK
IS_USED_LOCK
MASTER_POS_WAIT
RELEASE_LOCK
SLEEP
SYSDATE
VERSION
Fix: Mark these functions unsafe.
mysql-test/extra/rpl_tests/rpl_stm_000001.test:
- The test does not work in mixed mode any more, since it tries to
simulate an error in the sql thread in a query that uses get_lock.
Since get_lock now causes the query to be logged in row format,
the error didn't happen. Hence, we now force statement mode.
- Warnings must be disabled when the unsafe query is issued.
- Replaced some save_master_pos+connection slave+sync_with_master
by sync_slave_with_master.
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
updated result file
mysql-test/suite/binlog/r/binlog_stm_row.result:
updated result file
mysql-test/suite/binlog/r/binlog_unsafe.result:
updated result file
mysql-test/suite/binlog/t/binlog_killed.test:
binlog_killed only works in statement format now, since
it switches to row mode in mixed mode.
mysql-test/suite/binlog/t/binlog_stm_mix_innodb_myisam.test:
suppress warnings for unsafe statements
mysql-test/suite/binlog/t/binlog_stm_row.test:
- Suppress warnings in test that causes warnings.
- The test sets binlog format explicitly, so no need to execute it
twice.
mysql-test/suite/binlog/t/binlog_unsafe.test:
Added test for all unsafe system functions. This test also includes
system functions that were unsafe prior to BUG#47995.
mysql-test/suite/rpl/r/rpl_err_ignoredtable.result:
updated result file
mysql-test/suite/rpl/r/rpl_get_lock.result:
updated result file
mysql-test/suite/rpl/r/rpl_nondeterministic_functions.result:
new result file
mysql-test/suite/rpl/r/rpl_stm_000001.result:
updated result file
mysql-test/suite/rpl/r/rpl_trigger.result:
updated result file
mysql-test/suite/rpl/t/rpl_err_ignoredtable.test:
- suppress warnings for unsafe statement
- replaced save_master_pos+connection slave+sync_with_master
with sync_slave_with_master
mysql-test/suite/rpl/t/rpl_get_lock.test:
update test case that causes new warnings
mysql-test/suite/rpl/t/rpl_nondeterministic_functions.test:
Added new test case for nondeterministic functions.
mysql-test/suite/rpl/t/rpl_trigger.test:
update test case that causes new warnings
sql/item_create.cc:
Marked some system functions unsafe.
sql/item_strfunc.cc:
Clarified comment related to this bug.
sql/sql_yacc.yy:
Marked sysdate unsafe.
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.
When binlog_format is STATEMENT and the statement is unsafe before,
the unsafe warning/error message was issued without checking
whether the SQL_LOG_BIN was turned on or not.
Fixed with adding a sql_log_bin_toplevel flag in THD to check
whether SQL_LOG_BIN is ON in current session whatever the current is in sp or not.
mysql-test/suite/binlog/r/binlog_unsafe.result:
Test case result for unsafe warning/error message
mysql-test/suite/binlog/t/binlog_unsafe.test:
Test case for unsafe message warning/error
sql/set_var.cc:
Adding a function set_option_log_bin_bit() which specailly handles to
the change of SQL_LOG_BIN bit in order to set sql_log_bin_toplevel
according to SQL_LOG_BIN current value at the same time.
sql/sql_class.cc:
Initialize the flag sql_log_bin_toplevel in THD::init(),
and add the condition to check whether unsafe ror message was issued.
sql/sql_class.h:
Add a sql_log_bin_toplevel flag in THD to indicate whether the toplevel SQL_LOG_BIN is
The problem is that a unfiltered user query was being passed as
the format string parameter of sql_print_warning which later
performs printf-like formatting, leading to crashes if the user
query contains formatting instructions (ie: %s). Also, it was
using THD::query as the source of the user query, but this
variable is not meaningful in some situations -- in a delayed
insert, it points to the table name.
The solution is to pass the user query as a parameter for the
format string and use the function parameter query_arg as the
source of the user query.
mysql-test/suite/binlog/r/binlog_unsafe.result:
Add test case result for Bug#42634
mysql-test/suite/binlog/t/binlog_unsafe.test:
Add test case for Bug#42634
sql/sql_class.cc:
Don't pass the user query as a format string.
into stella.local:/home2/mydev/mysql-5.1-axmrg
mysql-test/r/federated.result:
Auto merged
mysql-test/t/federated.test:
Auto merged
sql/sql_delete.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_update.cc:
Auto merged
storage/federated/ha_federated.cc:
Auto merged
mysql-test/suite/binlog/r/binlog_unsafe.result:
Manual merge
mysql-test/suite/binlog/t/binlog_unsafe.test:
Manual merge
binlog_format=mixed
Statement-based replication of DELETE ... LIMIT, UPDATE ... LIMIT,
INSERT ... SELECT ... LIMIT is not safe as order of rows is not
defined.
With this fix, we issue a warning that this statement is not safe to
replicate in statement mode, or go to row-based mode in mixed mode.
Note that we may consider a statement as safe if ORDER BY primary_key
is present. However it may confuse users to see very similiar statements
replicated differently.
Note 2: regular UPDATE statement (w/o LIMIT) is unsafe as well, but
this patch doesn't address this issue. See comment from Kristian
posted 18 Mar 10:55.
mysql-test/suite/binlog/r/binlog_stm_ps.result:
Updated a test case according to fix for BUG#34768:
INSERT ... SELECT ... LIMIT is now replicated in row mode.
mysql-test/suite/binlog/r/binlog_unsafe.result:
A test case for BUG#34768.
mysql-test/suite/binlog/t/binlog_unsafe.test:
A test case for BUG#34768.
sql/sql_delete.cc:
Statement-based replication of DELETE ... LIMIT is not safe as order of
rows is not defined, so in mixed mode we go to row-based.
sql/sql_insert.cc:
Statement-based replication of INSERT ... SELECT ... LIMIT is not safe
as order of rows is not defined, so in mixed mode we go to row-based.
sql/sql_update.cc:
Statement-based replication of UPDATE ... LIMIT is not safe as order of
rows is not defined, so in mixed mode we go to row-based.
safe.
Fix: Move sql_mode: from the section of the test where safe variables are
tested, to the section where unsafe variables are tested.
mysql-test/suite/binlog/r/binlog_unsafe.result:
Updated result file of modified test.
Problem: in mixed and statement mode, a query that refers to a
system variable will use the slave's value when replayed on
slave. So if the value of a system variable is inserted into a
table, the slave will differ from the master.
Fix: mark statements that refer to a system variable as "unsafe",
meaning they will be replicated by row in mixed mode and produce a warning
in statement mode. There are some exceptions: some variables are actually
replicated. Those should *not* be marked as unsafe.
BUG#34732: mysqlbinlog does not print default values for auto_increment variables
Problem: mysqlbinlog does not print default values for some variables,
including auto_increment_increment and others. So if a client executing
the output of mysqlbinlog has different default values, replication will
be wrong.
Fix: Always print default values for all variables that are replicated.
I need to fix the two bugs at the same time, because the test cases would
fail if I only fixed one of them.
include/m_ctype.h:
Added definition of ILLEGAL_CHARSET_INFO_NUMBER. We just need a symbol
for a number that will never be used by any charset. ~0U should be safe
since charset numbers are sequential, starting from 0.
mysql-test/include/commit.inc:
Upated test to avoid making statements unsafe.
mysql-test/r/commit_1innodb.result:
Updated test needs updated result file.
mysql-test/r/mysqlbinlog.result:
Updated result file.
mysql-test/r/mysqlbinlog2.result:
Updated result file.
mysql-test/r/user_var-binlog.result:
Updated result file.
mysql-test/suite/binlog/r/binlog_base64_flag.result:
Updated result file.
mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result:
Updated result file.
mysql-test/suite/binlog/r/binlog_unsafe.result:
Modified test file needs modified result file.
mysql-test/suite/binlog/t/binlog_base64_flag.test:
Need to filter out pseudo_thread_id from result since it is
nondeterministic.
mysql-test/suite/binlog/t/binlog_unsafe.test:
Add tests that using variables is unsafe. The 'CREATE VIEW' tests didn't
make sense, so I removed them. SHOW WARNINGS is not necessary either,
because we get warnings for each statement in the result file.
mysql-test/suite/rpl/r/rpl_row_mysqlbinlog.result:
Updated result file.
mysql-test/suite/rpl/r/rpl_skip_error.result:
Updated result file.
mysql-test/suite/rpl/t/rpl_skip_error.test:
The test used @@server_id, which is not safe to replicate, so it would
have given a warning. The way it used @@server_id was hackish (issue a
query on master that removes rows only on master), so I replaced it by a
more robust way to do the same thing (connect to slave and insert the
rows only there).
Also clarified what the test case does.
mysql-test/t/mysqlbinlog2.test:
Use --short-form instead of manually filtering out nondeterministic stuff
from mysqlbinlog (because we added the nondeterministic @@pseudo_thread_id
to the output).
sql/item_func.cc:
Added method of Item_func_get_system_var that indicates whether the given
system variable will be written to the binlog or not.
sql/item_func.h:
Added method of Item_func_get_system_var that indicates whether the given
system variable will be written to the binlog or not.
sql/log_event.cc:
- auto_increment_offset was not written to the binlog if
auto_increment_increment=1
- mysqlbinlog did not output default values for some variables
(BUG#34732). In st_print_event_info, we remember for each variable whether
it has been printed or not. This is achieved in different ways for
different variables:
- For auto_increment_*, lc_time_names, charset_database_number,
we set the default values in st_print_event_info to something
illegal, so that it will look like they have changed the first time
they are seen.
- For charset, sql_mode, pseudo_thread_id, we add a flag to
st_print_event_info which indicates whether the variable has been
printed.
- Since pseudo_thread_id is now printed more often, and its value is
not guaranteed to be constant across different runs of the same
test script, I replaced it by a constant if --short-form is used.
- Moved st_print_event_info constructor from log_event.h to log_event.cc,
since it now depends on ILLEGAL_CHARSET_NUMBER, which is defined in
m_ctype.h, which is better to include from a .cc file than from a header
file.
sql/log_event.h:
Added fields to st_print_event_info that indicate whether some of the
variables have been written or not. Since the initialization of
charset_database_number now depends on ILLEGAL_CHARSET_INFO_NUMBER, which
is defined in a header file, which we'd better not include from this
header file -- I moved the constructor from here to log_event.cc.
sql/set_var.cc:
System variables now have a flag binlog_status, which indicates if they
are written to the binlog. If nothing is specified, all variables are
marked as not written to the binlog (NOT_IN_BINLOG) when created. In this
file, the variables that are written to the binlog are marked with
SESSION_VARIABLE_IN_BINLOG.
sql/set_var.h:
Added flag binlog_status to class sys_var. Added a getter and a
constructor parameter that sets it.
Since I had to change sys_var_thd_enum constructor anyways, I simplified
it to use default values of arguments instead of three copies of the
constructor.
sql/sql_yacc.yy:
Mark statements that refer to a system variable as "unsafe",
meaning they will be replicated by row in mixed mode. Added comment to
explain strange piece of code just above.
mysql-test/include/diff_tables.inc:
New auxiliary test file that tests whether two tables (possibly one on
master and one on slave) differ.
mysql-test/suite/rpl/r/rpl_variables.result:
New test case needs new result file.
mysql-test/suite/rpl/r/rpl_variables_stm.result:
New test file needs new result file.
mysql-test/suite/rpl/t/rpl_variables.test:
Test that INSERT of @@variables is replicated correctly (by switching to
row-based mode).
mysql-test/suite/rpl/t/rpl_variables_stm.test:
Test that replication of @@variables which are replicated explicitly works
as expected in statement mode (without giving warnings).
