Commit 46c730e6 authored by unknown's avatar unknown

Cleaning DROP TABLE which is important if the tests are run in a certain order.

This is because rpl_relayrotate.test uses InnoDB.
Example of a failing sequence:
rpl_relayrotate.test repl_user_variables.test rpl_relayrotate.test
Explaination in the files.
Btw all other tests which use InnoDB (innodb*.test) already have this final
DROP TABLE.
Removed a wrong comment of mine.


mysql-test/r/rpl_relayrotate.result:
  result update
mysql-test/t/rpl_relayrotate.test:
  cleaning DROP TABLE which is important if the tests are run in a certain order.
parent 1ad35518
......@@ -16,3 +16,4 @@ master_pos_wait('master-bin.001',3000,120)=-1
select * from t1 where a=8000;
a
8000
drop table t1;
......@@ -56,6 +56,14 @@ start slave;
# Detect this with timeout.
select master_pos_wait('master-bin.001',3000,120)=-1;
select * from t1 where a=8000;
# Note that the simple fact to have less than around 30 slave's binlogs
# (the slave is started with --log-slave-updates) is already
# a proof that the transaction was not properly resumed.
# The following DROP is a very important cleaning task:
# imagine the next test is run with --skip-innodb: it will do
# DROP TABLE IF EXISTS t1; but this will delete the frm and leave
# some data in the InnoDB datafile (because at that time mysqld
# does not know about InnoDB : --skip-innodb). So if later in the
# test suite a test wants to create an InnoDB table called t1, it
# will fail with
# InnoDB: Error: table t1 already exists in InnoDB internal
# InnoDB: data dictionary. Have you deleted the .frm file etc
drop table t1;
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment