Commit graph

3 commits

Author SHA1 Message Date
unknown
f32c08bd0c Bug #44331 Restore of database with events produces warning in replication
If an EVENT is created without the DEFINER clause set explicitly or with it set  
to CURRENT_USER, the master and slaves become inconsistent. This issue stems from 
the fact that in both cases, the DEFINER is set to the CURRENT_USER of the current 
thread. On the master, the CURRENT_USER is the mysqld's user, while on the slave,  
the CURRENT_USER is empty for the SQL Thread which is responsible for executing 
the statement.

To fix the problem, we do what follows. If the definer is not set explicitly,  
a DEFINER clause is added when writing the query into binlog; if 'CURRENT_USER' is 
used as the DEFINER, it is replaced with the value of the current user before 
writing to binlog.

mysql-test/suite/rpl/r/rpl_create_if_not_exists.result:
  Updated the result file after fixing bug#44331
mysql-test/suite/rpl/r/rpl_drop_if_exists.result:
  Updated the result file after fixing bug#44331
mysql-test/suite/rpl/r/rpl_events.result:
  Test result of Bug#44331
mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
  Updated the result file after fixing bug#44331
mysql-test/suite/rpl/t/rpl_events.test:
  Added test to verify if the definer is consistent between master and slave
  when the event is created without the DEFINER clause set explicitly or the
  DEFINER is set to CURRENT_USER
sql/events.cc:
  The "create_query_string" function is added to create a new query string 
  for removing executable comments.
sql/sql_yacc.yy:
  The remember_name token was added for recording the offset of EVENT_SYM.
2009-08-29 16:52:22 +08:00
Luis Soares
8db289c4d5 BUG#13684: post push fix for test case.
The test case relies on binlog entries for assertion. The problem is that the
binlog does not get cleaned in pushbuild between tests, resulting in extra
entries in the result file, causing the test to fail.
      
This fix adds a reset master at the beginning of the test, so that we get a
clean binlog file.
2009-02-11 18:46:43 +01:00
Luis Soares
b7b6773f69 BUG#13684: SP: DROP PROCEDURE|FUNCTION IF EXISTS not binlogged if routine does not exist
There is an inconsistency with DROP DATABASE IF EXISTS, DROP
TABLE IF EXISTS and DROP VIEW IF EXISTS: those are binlogged even
if the DB or TABLE does not exist, whereas DROP PROCEDURE IF
EXISTS does not. It would be nice or at least consistent if DROP
PROCEDURE/STATEMENT worked the same too.
      
Fixed DROP PROCEDURE|FUNCTION IF EXISTS by adding a call to
write_bin_log in mysql_execute_command. Checked also if all
documented "DROP (...) IF EXISTS" get binlogged. Left out DROP
SERVER IF EXISTS because it seems that it only gets binlogged when
using row event (see BUG#25705).
2009-02-10 11:52:19 +01:00