Detailed revision comments:
r6492 | sunny | 2010-01-21 09:38:35 +0200 (Thu, 21 Jan 2010) | 1 line
branches/5.1: Add reference to bug#47621 in the comment.
Detailed revision comments:
r6489 | sunny | 2010-01-21 02:57:50 +0200 (Thu, 21 Jan 2010) | 2 lines
branches/5.1: Factor out test for bug#44030 from innodb-autoinc.test
into a separate test/result files.
Detailed revision comments:
r6488 | sunny | 2010-01-21 02:55:08 +0200 (Thu, 21 Jan 2010) | 2 lines
branches/5.1: Factor out test for bug#44030 from innodb-autoinc.test
into a separate test/result files.
In RBR, DDL statement will change binlog format to non row-based
format before it is binlogged, but the binlog format was not be
restored, and then manipulating a temporary table can not reset binlog
format to row-based format rightly. So that the manipulated statement
is binlogged with statement-based format.
To fix the problem, restore the state of binlog format after the DDL
statement is binlogged.
mysql-test/extra/rpl_tests/rpl_tmp_table_and_DDL.test:
Added the test file to verify if executing DDL statement before
trying to manipulate a temporary table causes row-based replication
to break with error 'table does not exist'.
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
Correct the test result, all the above binlog event
should be row-based after the bug49132 is fixed IN RBR.
mysql-test/suite/ndb/r/ndb_tmp_table_and_DDL.result:
Test result for bug#49132 base on ndb engine.
mysql-test/suite/ndb/t/ndb_tmp_table_and_DDL.test:
Added the test file to verify if executing DDL statement before
trying to manipulate a temporary table causes row-based replication
to break with error 'table does not exist' base on ndb engine.
mysql-test/suite/rpl/r/rpl_tmp_table_and_DDL.result:
Test result for bug#49132 base on myisam engine.
mysql-test/suite/rpl/t/rpl_tmp_table_and_DDL.test:
Added the test file to verify if executing DDL statement before
trying to manipulate a temporary table causes row-based replication
to break with error 'table does not exist' base on myisam engine.
sql/event_db_repository.cc:
Added code to restore the state of binlog format after the DDL
statement is binlogged.
sql/events.cc:
Added code to restore the state of binlog format after the DDL
statement is binlogged.
sql/sp.cc:
Added code to restore the state of binlog format after the DDL
statement is binlogged.
sql/sql_acl.cc:
Added code to restore the state of binlog format after the DDL
statement is binlogged.
sql/sql_udf.cc:
Added code to restore the state of binlog format after the DDL
statement is binlogged.
cant find record
Some engines return data for the record. Despite the fact that
the null bit is set for some fields, their old value may still in
the row. This can happen when unpacking an AI from the binlog on
top of a previous record in which a field is set to NULL, which
previously contained a value. Ultimately, this may cause the
comparison of records to fail when the slave is doing an index or
range scan.
We fix this by deploying a call to reset() for each field that is
set to null while unpacking a row from the binary log.
Furthermore, we also add mixed mode test case to cover the
scenario where updating and setting a field to null through a
Query event and later searching it through a rows event will
succeed.
Finally, we also change the reset() method, from Field_bit class,
so that it takes into account bits stored among the null bits and
not only the ones stored in the record.
mysql-test/suite/rpl/t/rpl_set_null_innodb.test:
InnoDB test.
mysql-test/suite/rpl/t/rpl_set_null_myisam.test:
MyISAM test.
mysql-test/suite/rpl_ndb/t/rpl_ndb_set_null.test:
NDB test.
sql/field.h:
Changed reset so that it also clears the bits
among the null_bits for the Field_bit class.
sql/rpl_record.cc:
Resetting field after setting it to null when unpacking
row.
check_access() returning false for a database does not
guarantee that the access is granted to it.
This wrong condition in filling the INFORMATION_SCHEMA
tables causes extra tables to be returned to the user
even if he has no rights to see them.
Fixed by correcting the condition.
fulltext search and row op.
The search for fulltext indexes is searching for some special
predicate layouts. While doing so it's not checking for the number
of columns of the expressions it tries to calculate.
And since row expressions can't return a single scalar value there
was a crash.
Fixed by checking if the expressions are scalar (in addition to
being constant) before calling Item::val_xxx() methods.
Original revision:
------------------------------------------------------------
revision-id: li-bing.song@sun.com-20100130124925-o6sfex42b6noyc6x
parent: joro@sun.com-20100129145427-0n79l9hnk0q43ajk
committer: <Li-Bing.Song@sun.com>
branch nick: mysql-5.1-bugteam
timestamp: Sat 2010-01-30 20:49:25 +0800
message:
Bug #48321 CURRENT_USER() incorrectly replicated for DROP/RENAME USER;
REVOKE/GRANT; ALTER EVENT.
The following statements support the CURRENT_USER() where a user is needed.
DROP USER
RENAME USER CURRENT_USER() ...
GRANT ... TO CURRENT_USER()
REVOKE ... FROM CURRENT_USER()
ALTER DEFINER = CURRENT_USER() EVENT
but, When these statements are binlogged, CURRENT_USER() just is binlogged
as 'CURRENT_USER()', it is not expanded to the real user name. When slave
executes the log event, 'CURRENT_USER()' is expand to the user of slave
SQL thread, but SQL thread's user name always NULL. This breaks the replication.
After this patch, All above statements are rewritten when they are binlogged.
The CURRENT_USER() is expanded to the real user's name and host.
------------------------------------------------------------
Several items said to be deprecated in the 4.1 manual
have never been removed. This worklog adds deprecation
warnings when these items are used, and warns the user
that the items will be removed in MySQL 5.6.
A couple of previously deprecation decision have been
reversed (see single file comments)
client/client_priv.h:
Macro similar to the one in the server (mysql_priv.h)
for printing a deprecation warning message
client/mysql.cc:
no-auto-rehash will not be deprecated
skip-line-numbers will not be deprecated
skip-column-names will not be deprecated
no-pager is deprecated
set-variable is deprecated
no-named-commands is deprecated
client/mysqladmin.cc:
set-variable is deprecated
client/mysqlbinlog.cc:
position is deprecated
client/mysqldump.c:
first-slave is deprecated
no-set-names is deprecated
set-variable is deprecated
mysql-test/r/mysqlbinlog.result:
Adding the [Warning] to the test case, just to show that the
deprecation works.
The test case will be changed in Celosia to use --start-position.
mysys/my_getopt.c:
set-variable (include -O) is deprecated
scripts/mysqld_multi.sh:
Warning for mysqld_multi
sql/mysqld.cc:
default-collation is deprecated
log-bin-trust-routine-creators is deprecated
set-variable is deprecated
default-character-set is deprecated
safe-show-database is deprecated
sql/share/errmsg.txt:
Added version number for sql_log_update deprecation message.
It is well-known that due to concurrency issues, a slave can become
inconsistent when a transaction contains updates to both transaction and
non-transactional tables in statement and mixed modes.
In a nutshell, the current code-base tries to preserve causality among the
statements by writing non-transactional statements to the txn-cache which
is flushed upon commit. However, modifications done to non-transactional
tables on behalf of a transaction become immediately visible to other
connections but may not immediately get into the binary log and therefore
consistency may be broken.
In general, it is impossible to automatically detect causality/dependency
among statements by just analyzing the statements sent to the server. This
happen because dependency may be hidden in the application code and it is
necessary to know a priori all the statements processed in the context of
a transaction such as in a procedure. Moreover, even for the few cases that
we could automatically address in the server, the computation effort
required could make the approach infeasible.
So, in this patch we introduce the option
- "--binlog-direct-non-transactional-updates" that can be used to bypass
the current behavior in order to write directly to binary log statements
that change non-transactional tables.
mysql-test/extra/rpl_tests/rpl_mixing_engines.inc:
Backported this from Celosia to improve the test cases related to the NTM issue.
sql/log.cc:
Checks the --binlog-direct-non-transactional-updates before choosing
to either use the trxn-cache or not.
sql/mysqld.cc:
Introduces the option --binlog-direct-non-transactional-updates.
sql/set_var.cc:
Introduces the option --binlog-direct-non-transactional-updates.
sql/sql_class.h:
Introduces the option --binlog-direct-non-transactional-updates.
valgrind pointed to a buffer allocated by my_realloc which looked fishy
Replaced size with what was probably intended, added test case.
Now also fixed line after review comment
- The arguments are properly quoted when mtr.pl calls my_safe_process but
unfortunately the all off when running with active state perl and stays
in cygwin perl.
- Extend the patch to only quote args that are not already quoted
This a redo of previous commit, will be included in next push
'CREATE TABLE IF NOT EXISTS ... SELECT' statement were causing 'CREATE
TEMPORARY TABLE ...' to be written to the binary log in row-based
mode (a.k.a. RBR), when there was a temporary table with the same name.
Because the 'CREATE TABLE ... SELECT' statement was executed as
'INSERT ... SELECT' into the temporary table. Since in RBR mode no
other statements related to temporary tables are written into binary log,
this sometimes broke replication.
This patch changes behavior of 'CREATE TABLE [IF NOT EXISTS] ... SELECT ...'.
it ignores existence of temporary table with the
same name as table being created and is interpreted
as attempt to create/insert into base table. This makes behavior of
'CREATE TABLE [IF NOT EXISTS] ... SELECT' consistent with
how ordinary 'CREATE TABLE' and 'CREATE TABLE ... LIKE' behave.
to pick up the first part fix of bug49396.
------------------------------------------------------------------------
r6471 | calvin | 2010-01-15 17:43:27 -0600 (Fri, 15 Jan 2010) | 4 lines
branches/5.1: fix bug#49396: main.innodb test fails in embedded mode
Change replace_result by using $MYSQLD_DATADIR. Tested in both embedded
mode and normal server mode.
------------------------------------------------------------------------
BUG#49481: RBR: MyISAM and bit fields may cause slave to stop on delete:
cant find record
BUG#49482: RBR: Replication may break on deletes when MyISAM tables +
char field are used
When using MyISAM tables, despite the fact that the null bit is
set for some fields, their old value is still in the row. This
can cause the comparison of records to fail when the slave is
doing an index or range scan.
We fix this by avoiding memcmp for MyISAM tables when comparing
records. Additionally, when comparing field by field, we first
check if both fields are not null and if so, then we compare
them. If just one field is null we return failure immediately. If
both fields are null, we move on to the next field.
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.
Selecting of the CONCAT_WS(...<PS parameter>...) result into
a user variable may return wrong data.
Item_func_concat_ws::val_str contains a number of memory
allocation-saving optimization tricks. After the fix
for bug 46815 the control flow has been changed to a
branch that is commented as "This is quite uncommon!":
one of places where we are trying to concatenate
strings inplace. However, that "uncommon" place
didn't care about PS parameters, that have another
trick in Item_sp_variable::val_str(): they use the
intermediate Item_sp_variable::str_value field,
where they may store a reference to an external
argument's buffer.
The Item_func_concat_ws::val_str function has been
modified to take into account val_str functions
(such as Item_sp_variable::val_str) that return a
pointer to an internal Item member variable that
may reference to a buffer provided.
mysql-test/r/func_concat.result:
Added test case for bug #50096.
mysql-test/t/func_concat.test:
Added test case for bug #50096.
sql/item_strfunc.cc:
Bug #50096: CONCAT_WS inside procedure returning wrong data
The Item_func_concat_ws::val_str function has been
modified to take into account val_str functions
(such as Item_sp_variable::val_str) that return a
pointer to an internal Item member variable that
may reference to a buffer provided.
MySQL handles the join syntax "JOIN ... USING( field1,
... )" and natural joins by building the same parse tree as
a corresponding join with an "ON t1.field1 = t2.field1 ..."
expression would produce. This parse tree was not cleaned up
properly in the following scenario. If a thread tries to
lock some tables and finds that the tables were dropped and
re-created while waiting for the lock, it cleans up column
references in the statement by means a per-statement free
list. But if the statement was part of a stored procedure,
column references on the stored procedure's free list weren't
cleaned up and thus contained pointers to freed objects.
Fixed by adding a call to clean up the current prepared
statement's free list.
mysql-test/r/sp_sync.result:
Bug#48157: Test case
mysql-test/t/sp_sync.test:
Bug#48157: Test result
sql/item.h:
Bug#48157: Commented field.
sql/sql_parse.cc:
Bug#48157: Commented function.
sql/sql_update.cc:
Bug#48157: fix
Manually deleteing one or more entries from 'master-bin.index', will
cause master infinitely loop to send one binlog file.
When starting a dump session, master opens index file and search the binlog file
which is being requested by the slave. The position of the binlog file in the
index file is recorded. it will be used to find the next binlog file when current
binlog file has dumped completely. As only the position is used, it may
not get the correct file if some entries has been removed manually from the index file.
the master will reopen the current binlog file which has been dump completely
and redump it if it can not get the next binlog file's name from index file.
It obviously is a logical error.
Even though it is allowed to manually change index file,
but it is not recommended. so after this patch, master
sends a fatal error to slave and close the dump session if a new binlog file
has been generated and master can not get it from the index file.
