Commit graph

1027 commits

Author SHA1 Message Date
Nuno Carvalho
84bd6fec76 BUG#16541422: LOG-SLAVE-UPDATES + REPLICATE-WILD-IGNORE-TABLE FAILS FOR USER VARIABLES
Fixed possible uninitialized variable.
2013-03-27 11:19:29 +00:00
Andrei Elkin
9eb64ec5c0 Bug#16541422 LOG-SLAVE-UPDATES + REPLICATE-WILD-IGNORE-TABLE FAILS FOR USER VARIABLES
At logging a first Query referring a user var, the slave missed to log the user var.
It appears that at execution of a Uservar event the slaver applier
thought of the variable as already logged.
The reason of misjudgement is in coincidence of query id:s: of one that the thread
holds at Uservar execution and another one that the thread sees at the Query applying.
While the two are naturally different in the regular execution branch (as two computational
events are separated as individual events), in the deferred applying case the User var execution
effectively belongs to its Query processing.

Fixed with storing the Uservar parsing time (where desicion to defer is taken) query id 
to temporarily substitute with it the actual query id at the Uservar execution time
(along with its query).
Such manipulation mimics behaviour of the regular applying branch.

sql/log_event.cc:
  Storing the Uservar parsing time query id into a new member of the event
  to to temporarily substitute
  with it the actual thread id at the Uservar execution time.
sql/log_event.h:
  Storage for keeping query-id in User-var intance is added.
2013-03-26 19:24:01 +02:00
Pedro Gomes
7e8c887786 BUG#13545447: RPL_ROTATE_LOGS FAILS DUE TO CONCURRENCY ISSUES IN REP. CODE
In method mysql_binlog_send, right after detecting a EOF in the
read event loop, and before deciding if we should change to a new
binlog file there is a execution window where new events can be
written to the binlog and a rotation can happen. When reaching
the test, the function will then change to a new binlog file
ignoring all the events written in this window. This will result
in events not being replicated.

Only when the binlog is detected as deactivated in the event loop
of the dump thread, can we really know that no more events
remain. For this reason, this test is now made under the log lock
in the beginning of the event loop when reading the events.
2013-02-15 21:57:35 +00:00
Nuno Carvalho
d1378565bb BUG#16200555: EMPTY NAME FOR USER VARIABLE IS ALLOWED AND BREAKS STATEMENT BINARY LOGGING
On a previous fix, user variables with zero length name were incorrectly
considered as event corruption, despite that them are allowed by server.

Fix this wrong assumption by allowing again user variables with zero
length on binary log.
2013-01-28 19:05:09 +00:00
Venkatesh Duggirala
bc21e8cd69 Bug#11752707-SLAVE CRASHES IF RBR HAS AS DESTINATION A VIEW
RATHER THAN A TABLE

Problem: In RBR, If a table is converted into a view at slave,
(i.e., "drop table 'object1'" & "create view 'object1'"), then any
DML operations on the table at master are causing crash at slave.

Analysis: Slave prepares tables to be opened for DML list when it
receives Table_map_log_event(s). And the same list will be sent to
open_table function. Open_table logic assumes that if the list
contains a view object, it also contains "select_lex" object of
that view. In the above special case, the table object does not
contain 'select_lex' as it is base table at master. Since it
is a view at slave, open_table logic goes to 'mysql_make_view()'
function which assumes that 'select_lex' exists for the object.

Fix: While preparing 'tables to be opened' list, we should make 
sure that table required type is 'base table'. If it is not 
base table while opening the object, mysql_make_view will throw an 
error similar to 'object is not a base table' 

sql/log_event.cc:
  Restrict that all table_map_log_event's objects should be 
  base tables @ slave also.
2013-01-19 06:01:46 +05:30
Libing Song
bdfc4dc6c6 Bug#11764602 ASSERTION IN
FORMAT_DESCRIPTION_LOG_EVENT::CALC_SERVER_VERSION_SPLIT

Problem: When reading a Format_description_log_event, it supposes MySQL
version is always valid and DBUG_ASSERTION is used check the version number.
However, user may give a wrong binlog offset, even give a faked binary event
which includes an invalid MySQL version. This will cause server crash.

Fix: The assertions are removed and an error will be reported if MySQL
version in Format_description_log_event is invalid.
2012-12-01 08:04:33 +08:00
Nuno Carvalho
62503f9cf5 BUG#14629727: USER_VAR_EVENT IS MISSING RANGE CHECKS
Moved explicit instantiation of available_buffer and valid_buffer_range 
template functions to sql/log_event.cc.
2012-10-21 20:28:19 +01:00
Nuno Carvalho
f1d3b0f190 BUG#14629727: USER_VAR_EVENT IS MISSING RANGE CHECKS
This bug had two problems:
 P1) Reads out of bounds;
 P2) Writes out of bounds.

PROBLEM P1
----------
User_var_log_event unmarshalling from binlog was not performing range
checks when using name_len and val_len variables to walk on event
buffer.

Added range checks to User_var_log_event unmarshalling to prevent
unmarshalling errors.

PROBLEM P2
----------
User_var_log_event value was allocated on thread stack, what caused
stack frame errors when User_var_log_event value was bigger than thread
stack size.

Currently value is allocated on heap memory.
2012-10-12 08:32:10 +01:00
Rohit Kalhans
7c671a7ead BUG#14548159: Followup patch to fix some issues on PB2 2012-09-23 15:45:22 +05:30
Rohit Kalhans
5530c5e38d BUG#14548159: NUMEROUS CASES OF INCORRECT IDENTIFIER
QUOTING IN REPLICATION 

Problem: Misquoting or unquoted identifiers may lead to
incorrect statements to be logged to the binary log.

Fix: we use specialized functions to append quoted identifiers in
the statements generated by the server.
2012-09-22 17:50:51 +05:30
Andrei Elkin
eca29d5f33 merge from 5.1 repo. 2012-07-10 13:00:03 +03:00
Sujatha Sivakumar
13f7f00288 BUG#11762670:MY_B_WRITE RETURN VALUE IGNORED
Problem:
=======
The return value from my_b_write is ignored by: `my_b_write_quoted',
`my_b_write_bit',`Query_log_event::print_query_header'

Most callers of `my_b_printf' ignore the return value. `log_event.cc' 
has many calls to it. 

Analysis:
========
`my_b_write' is used to write data into a file. If the write fails it
sets appropriate error number and error message through my_error()
function call and sets the IO_CACHE::error == -1.
`my_b_printf' function is also used to write data into a file, it
internally invokes my_b_write to do the write operation. Upon
success it returns number of characters written to file and on error
it returns -1 and sets the error through my_error() and also sets
IO_CACHE::error == -1.  Most of the event specific print functions
for example `Create_file_log_event::print', `Execute_load_log_event::print'
etc are the ones which make several calls to the above two functions and
they do not check for the return value after the 'print' call. All the above 
mentioned abuse cases deal with the client side.

Fix:
===
As part of bug fix a check for IO_CACHE::error == -1 has been added at 
a very high level after the call to the 'print' function.  There are 
few more places where the return value of "my_b_write" is ignored
those are mentioned below.

+++ mysys/mf_iocache2.c    2012-06-04 07:03:15 +0000
@@ -430,7 +430,8 @@
           memset(buffz, '0', minimum_width - length2);
         else
           memset(buffz, ' ', minimum_width - length2);
-        my_b_write(info, buffz, minimum_width - length2);

+++ sql/log.cc	2012-06-08 09:04:46 +0000
@@ -2388,7 +2388,12 @@
     {
       end= strxmov(buff, "# administrator command: ", NullS);
       buff_len= (ulong) (end - buff);
-      my_b_write(&log_file, (uchar*) buff, buff_len);

At these places appropriate return value handlers have been added.

client/mysqlbinlog.cc:
  check for IO_CACHE::error == -1 has been added after the call to
  the event specific print functions
mysys/mf_iocache2.c:
  Added handler to check the written value of `my_b_write'
sql/log.cc:
  Added handler to check the written value of `my_b_write'
sql/log_event.cc:
  Added error simulation statements in `Create_file_log_event::print`
  and `Execute_load_query_log_event::print'
sql/rpl_utility.h:
  Removed the extra ';'
2012-07-10 14:23:17 +05:30
Andrei Elkin
e3c8fb4a1c Bug#14275000
Fixes for BUG11761686 left a flaw that managed to slip away from testing.
Only effective filtering branch was actually tested with a regression test
added to rpl_filter_tables_not_exist.
The reason of the failure is destuction of too early mem-root-allocated memory 
at the end of the deferred User-var's do_apply_event().

Fixed with bypassing free_root() in the deferred execution branch.
Deallocation of created in do_apply_event() items is done by the base code
through THD::cleanup_after_query() -> free_items() that the parent Query
can't miss.



sql/log_event.cc:
  Do not call free_root() in case the deferred User-var event.
  Necessary methods to the User-var class are added, do_apply_event() refined.
sql/log_event.h:
  Necessary methods to avoid destoying mem-root-based memory at
  User-var applying are defined.
2012-07-05 14:37:48 +03:00
Manish Kumar
4a2d65cc31 BUG#12400221 - 60926: BINARY LOG EVENTS LARGER THAN MAX_ALLOWED_PACKET
Problem
========
            
Replication breaks in the cases if the event length exceeds 
the size of master Dump thread's max_allowed_packet.
              
The reason why this failure is occuring is because the event length is
more than the total size of the max_allowed_packet, on addition of the  
max_event_header length exceeds the max_allowed_packet of the DUMP thread.
This causes the Dump thread to break replication and throw an error.
                      
That can happen e.g with row-based replication in Update_rows event.
            
Fix
====
          
The problem is fixed in 2 steps:

1.) The Dump thread limit to read event is increased to the upper limit
    i.e. Dump thread reads whatever gets logged in the binary log.

2.) On the slave side we increase the the max_allowed_packet for the
    slave's threads (IO/SQL) by increasing it to 1GB.

    This is done using the new server option (slave_max_allowed_packet)
    included, is used to regulate the max_allowed_packet of the  
    slave thread (IO/SQL) by the DBA, and facilitates the sending of
    large packets from the master to the slave.

    This causes the large packets to be received by the slave and apply
    it successfully.

sql/log_event.cc:
  The max_allowed_packet is not evaluated to the new option 
  slave_max_allowed_packet after the fix.
sql/log_event.h:
  Added the new option in the log_event.h file.
sql/mysqld.cc:
  Added a new option to the server.
sql/slave.cc:
  Increasing the session max_allowed_packet to a large value,
  i.e. not taking global(max_allowed) into consideration, for the slave's threads.
sql/sql_repl.cc:
  The dump thread's max_allowed_packet is set to the upper limit
  which makes it independent and it now reads whatever gets 
  logged in the binary log.
2012-06-12 12:59:13 +05:30
Rohit Kalhans
96eb519eb7 Fixing the build failure on Windows debug build. 2012-05-30 13:54:15 +05:30
Rohit Kalhans
d8b2d4a069 Bug#11762667: MYSQLBINLOG IGNORES ERRORS WHILE WRITING OUTPUT
Problem: mysqlbinlog exits without any error code in case of
file write error. It is because of the fact that the calls
to Log_event::print() method does not return a value and the
thus any error were being ignored.

Resolution: We resolve this problem by checking for the 
IO_CACHE::error == -1 after every call to Log_event:: print()
and terminating the further execution.

client/mysqlbinlog.cc:
  - handled error conditions during event->print() calls
  - added check for error in end_io_cache()
mysys/my_write.c:
  Added debug code to simulate file write error.
  error returned will be ENOSPC=> error no space on the disk
sql/log_event.cc:
  Added debug code to simulate file write error, by reducing the size of io cache.
2012-05-29 12:11:30 +05:30
Manish Kumar
1605b7f68f BUG#12400221 - 60926: BINARY LOG EVENTS LARGER THAN MAX_ALLOWED_PACKET
Problem
========
            
SQL statements close to the size of max_allowed_packet produce binary
log events larger than max_allowed_packet.
              
The reason why this failure is occuring is because the event length is
more than the total size of the max_allowed_packet + max_event_header
length. Now since the event length exceeds this size master Dump
thread is unable to send the packet on to the slave.
                      
That can happen e.g with row-based replication in Update_rows event.
            
Fix
====
          
The problem was fixed by increasing the max_allowed_packet for the
slave's threads (IO/SQL) by increasing it to 1GB.
This is done using the new server option included which is used to
regulate the max_allowed_packet of the slave thread (IO/SQL).
This causes the large packets to be received by the slave and apply
it successfully.

sql/log_event.h:
  Added the new option in the log_event.h file.
sql/mysqld.cc:
  Added a new option to the server.
sql/slave.cc:
  Increasing the session max_allowed_packet to a large value ,
  i.e. not taking global(max_allowed) into consideration, for the slave's threads.
2012-05-21 12:57:39 +05:30
Rohit Kalhans
781137c0dd BUG#14005409 - 64624
Problem: After the fix for Bug#12589870, a new field that
stores the length of db name was added in the buffer that
stores the query to be executed. Unlike for the plain user
session, the replication execution did not allocate the
necessary chunk in Query-event constructor. This caused an
invalid read while accessing this field.
      
Solution: We fix this problem by allocating a necessary chunk
in the buffer created in the Query_log_event::Query_log_event()
and store the length of database name.

sql/log_event.cc:
  Added a new field in the buffer created in the
  Query_log_event's constructor and store the length
  of database name.
2012-05-18 14:44:40 +05:30
Andrei Elkin
49e484c8cd BUG#11754117 incorrect logging of INSERT into auto-increment
BUG#11761686 insert_id event is not filtered.
  
Two issues are covered.
  
INSERT into autoincrement field which is not the first part in the composed primary key 
is unsafe by autoincrement logging design. The case is specific to MyISAM engine
because Innodb does not allow such table definition.
  
However no warnings and row-format logging in the MIXED mode was done, and
that is fixed.
  
Int-, Rand-, User-var log-events were not filtered along with their parent
query that made possible them to screw up execution context of the following
query.
  
Fixed with deferring their execution until the parent query.

******
Bug#11754117 

Post review fixes.

mysql-test/suite/rpl/r/rpl_auto_increment_bug45679.result:
  a new result file is added.
mysql-test/suite/rpl/r/rpl_filter_tables_not_exist.result:
  results updated.
mysql-test/suite/rpl/t/rpl_auto_increment_bug45679.test:
  regression test for BUG#11754117-45670 is added.
mysql-test/suite/rpl/t/rpl_filter_tables_not_exist.test:
  regression test for filtering issue of BUG#11754117 - 45670 is added.
sql/log_event.cc:
  Logics are added for deferring and executing events associated 
  with the Query event.
sql/log_event.h:
  Interface to deferred events batch execution is added.
sql/rpl_rli.cc:
  initialization for new RLI members is added.
sql/rpl_rli.h:
  New members to RLI are added to facilitate deferred events gathering
  and execution control;
  two general character RLI cleanup methods are constructed.
sql/rpl_utility.cc:
  Deferred_log_events methods are difined.
sql/rpl_utility.h:
  A new class Deferred_log_events is defined to implement
  IRU events gathering, execution and cleanup.
sql/slave.cc:
  Necessary changes to initialize `rli->deferred_events' and prevent
  deferred event deletion in the main read-exec branch.
sql/sql_base.cc:
  A new safe-check function for multi-part pk with auto-increment is defined
  and deployed in lock_tables().
sql/sql_class.cc:
  Initialization for a new member and replication cleanups are added
  to THD class.
sql/sql_class.h:
  THD class receives a new member to hold a specific execution
  context for slave applier.
sql/sql_parse.cc:
  Execution of the deferred event in started prior to its parent query.
2012-04-20 19:41:20 +03:00
Praveenkumar Hulakund
c22c9270fb Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION
Analysis:
========================
sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
instead of escape character in a string literal then sql_mode can be set to 
"NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
character like any other. 

SQL_MODE set applies to the current client session. And while creating the stored 
procedure, MySQL stores the current sql_mode and always executes the stored 
procedure in sql_mode stored with the Procedure, regardless of the server SQL 
mode in effect when the routine is invoked.  

In the scenario (for which bug is reported), the routine is created with 
sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
is "" (NOT SET) by executing statement "call testp('Axel\'s')".
Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
is considered as escape character and column "a" (of table "t1") values are 
updated with "Axel's". The binary log generated for above update operation is as below,

  set sql_mode=XXXXXX (for no_backslash_escapes)
  update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');

While logging stored procedure statements, the local variables (params) used in
statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
(http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)

On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
is also logged in. So that at slave this sql_mode is set before executing the statements
of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
and parsing reported error for "'" (as we have only one "'" no backslash). 

At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
But above error reported while writing bin log, "'" (of Axel's) is escaped with
"\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
while writing NAME_CONST for string variable(param, local variable) in bin log 
Airrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
that logging string parameter does not take into account sql_mode value.

Fix:
========================
So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
(n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
escape such characters while writing NAME_CONST for string variables in bin 
log. 
And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
represented as ''.
http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
ways to include quote characters within a string: )



mysql-test/r/sql_mode.result:
  Added test case for Bug#12601974.
mysql-test/suite/binlog/r/binlog_sql_mode.result:
  Appended result of test cases added for Bug#12601974.
mysql-test/suite/binlog/t/binlog_sql_mode.test:
  Added test case for Bug#12601974.
mysql-test/t/sql_mode.test:
  Appended result of test cases added for Bug#12601974.
2012-02-29 12:23:15 +05:30
Luis Soares
72857dc89c DBUG_PRINT in solaris does not work well with NULL parameters.
HA_ERR was returning 0 (null string) when no error happened 
(error=0). Since HA_ERR is used in DBUG_PRINT, regardless there 
was an error or not, the server could crash in solaris debug
builds.

We fix this by:

  - deploying an assertion that ensures that the function 
    is not called when no error has happened;
  - making sure that HA_ERR is only called when an error 
    happened;
  - making HA_ERR return "No Error", instead of 0, for 
    non-debug builds if it is called when no error happened.

This will make HA_ERR return values to work with DBUG_PRINT on
solaris debug builds.
2011-07-15 12:42:06 +01:00
Luis Soares
bf7d414b40 BUG#11753004: 44360: REPLICATION FAILED
The server crashes if it processes table map events that are
corrupted, especially if they map different tables to the same
identifier. This could happen, for instance, due to BUG 56226.
                  
We fix this by checking whether the table map has already been
mapped before actually applying the event. If it has been mapped
with different settings an error is raised and the slave SQL
thread stops. If it has been mapped with same settings the event
is skipped. If the table is set to be ignored by the filtering
rules, there is no change in behavior: the event is skipped and
ids are not checked.


mysql-test/suite/rpl/t/rpl_row_corruption.test:
  Added a simple test case that checks both cases:
  - multiple table maps with the same identifier
  - multiple table maps with the same identifier, but only one
    is processed (the others are filtered out)
2011-07-14 12:15:24 +01:00
Kent Boortz
027b5f1ed4 Updated/added copyright headers 2011-07-03 17:47:37 +02:00
Kent Boortz
68f00a5686 Updated/added copyright headers 2011-06-30 17:37:13 +02:00
Kent Boortz
44135d4725 Updated/added copyright headers 2011-06-30 17:31:31 +02:00
Luis Soares
b489c89f73 BUG#11766865: 60091: RBR + NO PK + UPDATE NULL VALUE --> SLAVE BREAK WITH ERROR HA_ERR_END_OF_
The slave was not able to find the correct row in the innodb
table, because the row fetched from the innodb table would not
match the before image. This happened because the (don't care)
bytes in the NULLed fields would change once the row was stored
in the storage engine (from zero to the default value). This
would make bulk memory comparison (using memcmp) to fail.
  
We fix this by taking a preventing measure and avoiding memcmp
for tables that contain nullable fields. Therefore, we protect
the slave search routine from engines that return arbitrary
values for don't care bytes (in the nulled fields). Instead, the
slave thread will only check null_bits and those fields that are
not set to NULL when comparing the before image against the
storage engine row.

mysql-test/extra/rpl_tests/rpl_record_compare.test:
  Added test case to the include file so that this is tested 
  with more than one engine.
mysql-test/suite/rpl/r/rpl_row_rec_comp_innodb.result:
  Result update.
mysql-test/suite/rpl/r/rpl_row_rec_comp_myisam.result:
  Result update.
mysql-test/suite/rpl/t/rpl_row_rec_comp_myisam.test:
  Moved the include file last, so that the result from
  BUG#11766865 is not intermixed with the result for
  BUG#11760454.
sql/log_event.cc:
  Skips memory comparison if the table has nullable 
  columns and compares only non-nulled fields in the
  field comparison loop.
2011-03-24 10:52:40 +00:00
unknown
22639a066c Bug mysqlbinlog not handling drop of current default database
mysqlbinlog only prints "use $database" statements to its output stream
when the active default database changes between events. This will cause
"No Database Selected" error when dropping and recreating that database.

To fix the problem, we clear print_event_info->db when printing an event
of CREATE/DROP/ALTER database statements, so that the Query_log_event
after such statements will be printed with the use 'db' anyway except
transaction keywords.

mysql-test/r/mysqlbinlog.result:
  Test result for Bug#50914.
mysql-test/t/mysqlbinlog.test:
  Added test to verify if the approach of the mysqlbinlog prints
  "use $database" statements to its output stream will cause
  "No Database Selected" error when dropping and recreating
  that database.
sql/log_event.cc:
  Updated code to clear print_event_info->db when printing an event
  of CREATE/DROP/ALTER database statements, so that the Query_log_event
  after such statements will be printed with the use 'db' anyway except
  transaction keywords.
2010-12-29 11:52:57 +08:00
unknown
d5bf6b8aa8 Bug Assertion failed: next_insert_id == 0, file .\handler.cc
Normally, auto_increment value is generated for the column by
inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO
suppresses this behavior for 0 so that only NULL generates
the auto_increment value. This behavior is also followed by
a slave, specifically by the SQL Thread, when applying events
in the statement format from a master. However, when applying
events in the row format, the flag was ignored thus causing
an assertion failure:
"Assertion failed: next_insert_id == 0, file .\handler.cc"

In fact, we never need to generate a auto_increment value for
the column when applying events in row format on slave. So we
don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'.

Refactoring: Get rid of all the sql_mode checks to rows_log_event
when applying it for avoiding problems caused by the inconsistency
of the sql_mode on slave and master as the sql_mode is not set for
Rows_log_event.

mysql-test/extra/rpl_tests/rpl_auto_increment.test:
  Added test to verify if the assertion of "next_insert_id == 0"
  will fail in ha_external_lock() function.
mysql-test/suite/rpl/r/rpl_auto_increment.result:
  Test result for bug#56662.
sql/log_event.cc:
  Added code to not allow generation of auto_increment value when
  processing rows event by adding 'MODE_NO_AUTO_VALUE_ON_ZERO' to
  sql_mode.
sql/rpl_record.cc:
  Added code to get rid of the 'MODE_STRICT_TRANS_TABLES'  and
  MODE_STRICT_ALL_TABLES check to the table when appling the
  rows event and treat it as no strict.
2010-12-21 12:47:22 +08:00
Luis Soares
92a0463edb BUG 46697
Addressing review comments.
2010-12-14 16:43:25 +00:00
Luis Soares
844138c90b BUG#46697: Table name in error message is not populated
When a query fails with a different error on the slave,
the sql thread outputs a message (M) containing:

  1. the error message format for the master error code
  2. the master error code
  3. the error message for the slave's error code
  4. the slave error code

Given that the slave has no information on the error message
itself that the master outputs, it can only print its own
version of the message format (but stripped from the 
additional data if the message format requires). This may
confuse users.

To fix this we augment the slave's message (M) to explicitly
state that the master's message is actually an error message 
format, the one associated with the given master error code 
and that the slave server knows about.
2010-12-03 17:17:45 +00:00
unknown
06c49d571b Bug#27606 GRANT statement should be replicated with DEFINER information
"Grantor" columns' data is lost when replicating mysql.tables_priv.
Slave SQL thread used its default user ''@'' as the grantor of GRANT|REVOKE
statements executing on it.

In this patch, current user is put in query log event for all GRANT and REVOKE
statement, SQL thread uses the user in query log event as grantor.


mysql-test/suite/rpl/r/rpl_do_grant.result:
  Add test for this bug.
mysql-test/suite/rpl/t/rpl_do_grant.test:
  Add test for this bug.
sql/log_event.cc:
  Refactoring THD::current_user_used and related functions.
  current_user_used is used to judge if current user should be
  binlogged in query log event. So it is better to call it m_binlog_invoker.
  The related functions are renamed too.
sql/sql_class.cc:
  Refactoring THD::current_user_used and related functions.
  current_user_used is used to judge if current user should be
  binlogged in query log event. So it is better to call it m_binlog_invoker.
  The related functions are renamed too.
sql/sql_class.h:
  Refactoring THD::current_user_used and related functions.
  current_user_used is used to judge if current user should be
  binlogged in query log event. So it is better to call it m_binlog_invoker.
  The related functions are renamed too.
sql/sql_parse.cc:
  Call binlog_invoker() for GRANT and REVOKE statements.
2010-10-23 20:55:44 +08:00
unknown
6646fecc14 Bug#55478 Row events wrongly apply on the temporary table of the same name
Rows events were applied wrongly on the temporary table with the same name.
But rows events are generated only for base tables. As temporary
table's data never be binlogged on row mode. Normally, base table of the
same name cannot be updated if a temporary table has the same name.
But there are two cases which can generate rows events on 
the base table of same name.
      
Case1: 'CREATE TABLE ... SELECT' statement.
In mixed format, it will generate rows events if it is unsafe.
      
Case2: Drop a transactional temporary table in a transaction
       (happens only on 5.5+).
BEGIN;
DROP TEMPORARY TABLE t1;       # t1 is a InnoDB table
INSERT INTO t1 VALUES(rand()); # t1 is a MyISAM table
COMMIT;
'DROP TEMPORARY TABLE' will be put in the transaction cache and
binlogged after the rows events generated by the 'INSERT' statement.
      
After this patch, slave opens only base table when applying a rows event.
2010-10-21 13:43:19 +08:00
Davi Arnaut
1040f98ccf Bug#45288: pb2 returns a lot of compilation warnings
Tag or remove unused arguments and variables.

regex/main.c:
  Use the real prototype.
sql/ha_ndbcluster.cc:
  Make conditions less ambiguous.
2010-10-19 20:36:59 -02:00
Luis Soares
6739a84529 BUG 38718: automerged bzr bundle from bug report into
latest mysql-5.1-bugteam.
2010-10-13 08:25:43 +01:00
unknown
10812c0782 Bug#55375 Transaction bigger than max_binlog_cache_size crashes slave
When slave executes a transaction bigger than slave's max_binlog_cache_size,
slave will crash. It is caused by the assert that server should only roll back
the statement but not the whole transaction if the error ER_TRANS_CACHE_FULL 
happens. But slave sql thread always rollbacks the whole transaction when
an error happens.
            
Ather this patch, we always clear any error set in sql thread(it is different
from the error in 'SHOW SLAVE STATUS') and it is cleared before rolling back
the transaction.


mysql-test/suite/rpl/r/rpl_binlog_max_cache_size.result:
  SET binlog_cache_size and max_binlog_cache_size for all test cases.
  Add test case for bug#55375.
mysql-test/suite/rpl/t/rpl_binlog_max_cache_size-master.opt:
  binlog_cache_size and max_binlog_cache_size can be set in the client connection.
  so remove this option file.
mysql-test/suite/rpl/t/rpl_binlog_max_cache_size.test:
  SET binlog_cache_size and max_binlog_cache_size for all test cases.
  Add test case for bug#55375.
sql/log_event.cc:
  Some functions don't return the error code, so it is a wrong error code.
  The error should always be set into thd->main_da. So we use 
  slave_rows_error_report to report the right error.
sql/slave.cc:
  exec_relay_log_event() need call cleanup_context() to clear context. 
  clearup_context() will call end_trans().
          
  Clear thd's error before cleanup_context. It avoid to trigger the assert
  which cause this bug.
2010-10-09 15:05:43 +08:00
Luis Soares
c93eecdf0a BUG#38718: slave sql thread crashes when reading relay log
Suprisingly, a Slave_log_event would show up in the binary
log. This event is never used and should not appear in the
logs. As such, when the slave (or the mysqlbinlog tool) reads the
event, it will hit an invalid pointer (reference to the
descriptor event when deserializing the Slave_log_event was
purposodely set to NULL).
      
The presence of the Slave_log_event denotes a corrupted log, but
we cannot tell how the log got corrupted in the first
place. However, we can make the server cope with such events when
it reads them - in case of log corruption - and fail gracefully.
     
This patch makes the server/mysqlbinlog to report that it has
found an invalid log event when Slave_log_event is read.
2010-10-06 12:23:46 +01:00
Davi Arnaut
11fae04527 Bug#45288: pb2 returns a lot of compilation warnings on linux
Although the C standard mandates that sprintf return the number
of bytes written, some very ancient systems (i.e. SunOS 4)
returned a pointer to the buffer instead. Since these systems
are not supported anymore and are hopefully long dead by now,
simply remove the portability wrapper that dealt with this
discrepancy. The autoconf check was causing trouble with GCC.
2010-07-09 09:00:17 -03:00
unknown
625ae7185a Postfix bug#48321
Fix the memory leak
2010-07-08 10:44:26 +08:00
unknown
1a17d7e807 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() EVENTbut, 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, session's user will be written into query log events 
if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.


mysql-test/include/diff_tables.inc:
  Expend its abilities.
  Now it can diff not only in sessions of 'master' and 'slave', but 
  other sessions as well.
sql/log_event.cc:
  session's user will be written into Query_log_event, if is_current_user_used() is TRUE.
  On slave SQL thread, Only thd->invoker is written into Query_log_event,
  if it exists.
sql/sql_acl.cc:
  On slave SQL thread, grantor should copy from thd->invoker, if it exists
sql/sql_class.h:
  On slave SQL thread, thd->invoker is used to store the applying event's
  invoker.
2010-07-04 12:02:49 +08:00
Davi Arnaut
0eb26fdfa8 Bug#53445: Build with -Wall and fix warnings that it generates
Apart strict-aliasing warnings, fix the remaining warnings
generated by GCC 4.4.4 -Wall and -Wextra flags.

One major source of warnings was the in-house function my_bcmp
which (unconventionally) took pointers to unsigned characters
as the byte sequences to be compared. Since my_bcmp and bcmp
are deprecated functions whose only difference with memcmp is
the return value, every use of the function is replaced with
memcmp as the special return value wasn't actually being used
by any caller.

There were also various other warnings, mostly due to type
mismatches, missing return values, missing prototypes, dead
code (unreachable) and ignored return values.

BUILD/SETUP.sh:
  Remove flags that are implied by -Wall and -Wextra.
  Do not warn about unused parameters in C++.
BUILD/check-cpu:
  Print only the compiler version instead of verbose banner.
  Although the option is gcc specific, the check was only
  being used for GCC specific checks anyway.
client/mysql.cc:
  bcmp is no longer defined.
client/mysqltest.cc:
  Pass a string to function expecting a format string.
  Replace use of bcmp with memcmp.
cmd-line-utils/readline/Makefile.am:
  Always define _GNU_SOURCE when compiling GNU readline.
  Required to make certain prototypes visible.
cmd-line-utils/readline/input.c:
  Condition for the code to be meaningful.
configure.in:
  Remove check for bcmp.
extra/comp_err.c:
  Use appropriate type.
extra/replace.c:
  Replace use of bcmp with memcmp.
extra/yassl/src/crypto_wrapper.cpp:
  Do not ignore the return value of fgets. Retrieve the file
  position if fgets succeed -- if it fails, the function will
  bail out and return a error.
extra/yassl/taocrypt/include/blowfish.hpp:
  Use a single array instead of accessing positions of the sbox_
  through a subscript to pbox_.
extra/yassl/taocrypt/include/runtime.hpp:
  One definition of such functions is enough.
extra/yassl/taocrypt/src/aes.cpp:
  Avoid potentially ambiguous conditions.
extra/yassl/taocrypt/src/algebra.cpp:
  Rename arguments to avoid shadowing related warnings.
extra/yassl/taocrypt/src/blowfish.cpp:
  Avoid potentially ambiguous conditions.
extra/yassl/taocrypt/src/integer.cpp:
  Do not define type within a anonymous union.
  Use a variable to return a value instead of
  leaving the result in a register -- compiler
  does not know the logic inside the asm.
extra/yassl/taocrypt/src/misc.cpp:
  Define handler for pure virtual functions.
  Remove unused code.
extra/yassl/taocrypt/src/twofish.cpp:
  Avoid potentially ambiguous conditions.
extra/yassl/testsuite/test.hpp:
  Function must have C language linkage.
include/m_string.h:
  Remove check which relied on bcmp being defined -- they weren't
  being used as bcmp is only visible when _BSD_SOURCE is defined.
include/my_bitmap.h:
  Remove bogus helpers which were used only in a few files and
  were causing warnings about dead code.
include/my_global.h:
  Due to G++ bug, always silence false-positive uninitialized
  variables warnings when compiling C++ code with G++.
  Remove bogus helper.
libmysql/Makefile.shared:
  Remove built-in implementation of bcmp.
mysql-test/lib/My/SafeProcess/safe_process.cc:
  Cast pid to largest possible type for a process identifier.
mysys/mf_loadpath.c:
  Leave space of the ending nul.
mysys/mf_pack.c:
  Replace bcmp with memcmp.
mysys/my_bitmap.c:
  Dead code removal.
mysys/my_gethwaddr.c:
  Remove unused variable.
mysys/my_getopt.c:
  Silence bogus uninitialized variable warning.
  Do not cast away the constant qualifier.
mysys/safemalloc.c:
  Cast to expected type.
mysys/thr_lock.c:
  Silence bogus uninitialized variable warning.
sql/field.cc:
  Replace bogus helper with a more appropriate logic which is
  used throughout the code.
sql/item.cc:
  Remove bogus logical condition which always evaluates to TRUE.
sql/item_create.cc:
  Simplify code to avoid signedness related warnings.
sql/log_event.cc:
  Replace use of bcmp with memcmp.
  No need to use helpers for simple bit operations.
sql/log_event_old.cc:
  Replace bmove_align with memcpy.
sql/mysqld.cc:
  Move use declaration of variable to the ifdef block where it
  is used. Remove now-unnecessary casts and arguments.
sql/set_var.cc:
  Replace bogus helpers with simple and classic bit operations.
sql/slave.cc:
  Cast to expected type and silence bogus warning.
sql/sql_class.h:
  Don't use enum values as bit flags, the supposed type safety is
  bogus as the combined bit flags are not a value in the enumeration.
sql/udf_example.c:
  Only declare variable when necessary.
sql/unireg.h:
  Replace use of bmove_align with memcpy.
storage/innobase/os/os0file.c:
  Silence bogus warning.
storage/myisam/mi_open.c:
  Remove bogus cast, DBUG_DUMP expects a pointer to unsigned
  char.
storage/myisam/mi_page.c:
  Remove bogus cast, DBUG_DUMP expects a pointer to unsigned
  char.
strings/bcmp.c:
  Remove built-in bcmp.
strings/ctype-ucs2.c:
  Silence bogus warning.
tests/mysql_client_test.c:
  Use a appropriate type as expected by simple_command().
2010-07-02 15:30:47 -03:00
Davi Arnaut
bfd3b7a109 Revert Bug#48321 due to build breakage and failing tests. 2010-06-28 17:59:41 -03:00
Alfranio Correia
77854696c4 merge mysql-5.1-bugteam (local) --> mysql-5.1-bugteam 2010-06-27 18:31:42 +01:00
unknown
451cea3f62 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() EVENTbut, 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, session's user will be written into query log events 
if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.


mysql-test/include/diff_tables.inc:
  Expend its abilities.
  Now it can diff not only in sessions of 'master' and 'slave', but 
  other sessions as well.
mysql-test/include/rpl_diff_tables.inc:
  Diff the same table between master and slaves.
sql/log_event.cc:
  session's user will be written into Query_log_event, if is_current_user_used() is TRUE.
  On slave SQL thread, Only thd->variables.current_user is written into Query_log_event,
  if it exists.
sql/sql_acl.cc:
  On slave SQL thread, grantor should copy from thd->variables.current_user, if it exists
sql/sql_class.h:
  On slave SQL thread, thd->variables.current_user is used to store the applying event's
  invoker.
2010-06-27 12:42:06 +08:00
Alfranio Correia
cdc4e9ebce merge mysql-5.1-bugteam (local) --> mysql-5.1-bugteam 2010-06-17 01:25:07 +01:00
Luis Soares
1b61dcf434 BUG#53893: RBR: nullable unique key can lead to out-of-sync slave
Post-push fix.
  
There was a valgrind issue on the loop that checks whether there
are NULL fields in the UNIQUE KEY or not. In detail, for the last 
iteration the server may read out of the key_part array boundaries,
making valgrind to output warnings.

We fix this by correcting the loop, ie, moving the part that reads
from the key_part to be inside the loop statement block. This way
the assignment is protected by the loop condition.
2010-06-04 00:45:07 +01:00
Luis Soares
1b27674429 BUG#53893: RBR: nullable unique key can lead to out-of-sync slave
When using Unique Keys with nullable parts in RBR, the slave can
choose the wrong row to update. This happens because a table with
an unique key containing nullable parts cannot strictly guarantee 
uniqueness. As stated in the manual, for all engines, a UNIQUE 
index allows multiple NULL values for columns that can contain 
NULL.

We fix this at the slave by extending the checks before assuming
that the row found through an unique index is is the correct
one. This means that when a record (R) is fetched from the storage
engine and a key that is not primary (K) is used, the server does 
the following: 

 - If K is unique and has no nullable parts, it returns R;
 - Otherwise, if any field in the before image that is part of K
   is null do an index scan;
 - If there is no NULL field in the BI part of K, then return R.

A side change: renamed the existing test case file and added a
test case covering the changes in this patch.
2010-06-02 23:26:12 +01:00
Luis Soares
779241bc94 BUG 52868: automerged bzr bundle from bug report. 2010-05-20 00:50:42 +01:00
Alfranio Correia
3f8bde448c BUG#53560 CREATE TEMP./DROP TEMP. are not binglogged correctly after a failed statement
This patch fixes two problems described as follows:

1 - If there is an on-going transaction and a temporary table is created or
dropped, any failed statement that follows the "create" or "drop commands"
triggers a rollback and by consequence the slave will go out sync because
the binary log will have a wrong sequence of events.

To fix the problem, we changed the expression that evaluates when the
cache should be flushed after either the rollback of a statment or
transaction.

2 - When a "CREATE TEMPORARY TABLE SELECT * FROM" was executed the
OPTION_KEEP_LOG was not set into the thd->options. For that reason, if
the transaction had updated only transactional engines and was rolled
back at the end (.e.g due to a deadlock) the changes were not written
to the binary log, including the creation of the temporary table.
      
To fix the problem, we have set the OPTION_KEEP_LOG into the thd->options
when a "CREATE TEMPORARY TABLE SELECT * FROM" is executed.

sql/log.cc:
  Reorganized the code based on the following functions:
  
  - bool ending_trans(const THD* thd, const bool all);
  - bool trans_has_updated_non_trans_table(const THD* thd);
  - bool trans_has_no_stmt_committed(const THD* thd, const bool all);
  - bool stmt_has_updated_non_trans_table(const THD* thd);
sql/log.h:
  Added functions to organize the code in log.cc.
sql/log_event.cc:
  Removed the OPTION_KEEP_LOG since it must be used only when
  creating and dropping temporary tables.
sql/log_event_old.cc:
  Removed the OPTION_KEEP_LOG since it must be used only when
  creating and dropping temporary tables.
sql/sql_parse.cc:
  When a "CREATE TEMPORARY TABLE SELECT * FROM" was executed the
  OPTION_KEEP_LOG was not set into the thd->options.
        
  To fix the problem, we have set the OPTION_KEEP_LOG into the
  thd->options when a "CREATE TEMPORARY TABLE SELECT * FROM"
  is executed.
2010-05-19 18:01:12 +01:00
Luis Soares
2646306cc9 BUG#49522: Replication problem with mixed MyISAM/InnoDB
When using a non-transactional table (t1) on the master 
and with autocommit disabled, no COMMIT is recorded 
in the binary log ending the statement. Therefore, if 
the slave has t1 in a transactional engine, then it will 
be as if a transaction is started but never ends. This is
actually BUG#29288 all over again.

We fix this by cherrypicking the cset for BUG#29288 which
was pushed to a later mysql version. The revision picked
was: mats@sun.com-20090923094343-bnheplq8n95opjay .

Additionally, a test case for covering the scenario depicted
in the bug report is included in this cset.
2010-05-07 18:48:35 +01:00
Luis Soares
fbe81e3c97 BUG#52868: Wrong handling of NULL value during update, replication out
of sync

In RBR, sometimes the table->s->last_null_bit_pos can be zero. This
has impact at the slave when it compares records fetched from the
storage engine against records in the binary log event. If
last_null_bit_pos is zero the slave, while comparing in
log_event.cc:record_compare function, would set all bits in the last
null_byte to 1 (assumed all 8 were unused) . Thence it would loose the
ability to distinguish records that were similar in contents except
for the fact that some field was null in one record, but not in the
other. Ultimately this would cause wrong matches, and in the specific
case depicted in the bug report the same record would be updated
twice, resulting in a lost update.

Additionally, in the record_compare function the slave was setting the
X bit unconditionally. There are cases that the X bit does not exist
in the record header. This could also lead to wrong matches between
records.

We fix both by conditionally resetting the bits: (i) unused null_bits
are set if last_null_bit_pos > 0; (ii) X bit is set if
HA_OPTION_PACK_RECORD is in use.

mysql-test/extra/rpl_tests/rpl_record_compare.test:
  Shared part of the test case for MyISAM and InnoDB.
mysql-test/suite/rpl/t/rpl_row_rec_comp_innodb.test:
  InnoDB test case.
mysql-test/suite/rpl/t/rpl_row_rec_comp_myisam.test:
  MyISAM test case. Added also coverage for Field_bits case.
sql/log_event.cc:
  Deployed conditional setting of unused bits at record_compare.
sql/log_event_old.cc:
  Same change as in log_event.cc.
2010-04-21 13:47:55 +01:00