mariadb/mysql-test/suite/rpl/r/rpl_row_create_table.result

474 lines
11 KiB
Text
Raw Normal View History

stop slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
reset master;
reset slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
start slave;
**** Resetting master and slave ****
include/stop_slave.inc
RESET SLAVE;
RESET MASTER;
include/start_slave.inc
CREATE TABLE t1 (a INT, b INT);
CREATE TABLE t2 (a INT, b INT) ENGINE=Merge;
CREATE TABLE t3 (a INT, b INT) CHARSET=utf8;
CREATE TABLE t4 (a INT, b INT) ENGINE=Merge CHARSET=utf8;
SHOW BINLOG EVENTS FROM 107;
Log_name #
Pos 107
Event_type Query
Server_id #
End_log_pos 200
Info use `test`; CREATE TABLE t1 (a INT, b INT)
Log_name #
Pos 200
Event_type Query
Server_id #
End_log_pos 306
Info use `test`; CREATE TABLE t2 (a INT, b INT) ENGINE=Merge
Log_name #
Pos 306
Event_type Query
Server_id #
End_log_pos 412
Info use `test`; CREATE TABLE t3 (a INT, b INT) CHARSET=utf8
Log_name #
Pos 412
Event_type Query
Server_id #
End_log_pos 531
Info use `test`; CREATE TABLE t4 (a INT, b INT) ENGINE=Merge CHARSET=utf8
**** On Master ****
SHOW CREATE TABLE t1;
Table t1
Create Table CREATE TABLE `t1` (
2006-03-06 20:12:48 +01:00
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
SHOW CREATE TABLE t2;
Table t2
Create Table CREATE TABLE `t2` (
2006-03-06 20:12:48 +01:00
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
2008-03-14 21:37:19 +01:00
) ENGINE=MRG_MyISAM DEFAULT CHARSET=latin1
SHOW CREATE TABLE t3;
Table t3
Create Table CREATE TABLE `t3` (
2006-03-06 20:12:48 +01:00
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8
**** On Slave ****
SHOW CREATE TABLE t1;
Table t1
Create Table CREATE TABLE `t1` (
2006-03-06 20:12:48 +01:00
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
) ENGINE=MEMORY DEFAULT CHARSET=latin1
SHOW CREATE TABLE t2;
Table t2
Create Table CREATE TABLE `t2` (
2006-03-06 20:12:48 +01:00
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
2008-03-14 21:37:19 +01:00
) ENGINE=MRG_MyISAM DEFAULT CHARSET=latin1
SHOW CREATE TABLE t3;
Table t3
Create Table CREATE TABLE `t3` (
2006-03-06 20:12:48 +01:00
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
) ENGINE=MEMORY DEFAULT CHARSET=utf8
CREATE TABLE t5 (b INT, c INT) SELECT * FROM t3;
CREATE TEMPORARY TABLE tt3 (a INT, b INT);
INSERT INTO tt3 VALUES (1,2), (2,4), (3,6), (4,2), (5,10), (6,12);
CREATE TABLE t6 (b INT, c INT) SELECT * FROM tt3;
**** On Master ****
SHOW CREATE TABLE t5;
Table t5
Create Table CREATE TABLE `t5` (
2006-03-06 20:12:48 +01:00
`c` int(11) DEFAULT NULL,
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
SELECT * FROM t5 ORDER BY a,b,c;
c a b
SHOW CREATE TABLE t6;
Table t6
Create Table CREATE TABLE `t6` (
2006-03-06 20:12:48 +01:00
`c` int(11) DEFAULT NULL,
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
SELECT * FROM t6 ORDER BY a,b,c;
c a b
NULL 1 2
NULL 2 4
NULL 3 6
NULL 4 2
NULL 5 10
NULL 6 12
**** On Slave ****
SHOW CREATE TABLE t5;
Table t5
Create Table CREATE TABLE `t5` (
2006-03-06 20:12:48 +01:00
`c` int(11) DEFAULT NULL,
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
) ENGINE=MEMORY DEFAULT CHARSET=latin1
SELECT * FROM t5 ORDER BY a,b,c;
c a b
SHOW CREATE TABLE t6;
Table t6
Create Table CREATE TABLE `t6` (
2006-03-06 20:12:48 +01:00
`c` int(11) DEFAULT NULL,
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
) ENGINE=MEMORY DEFAULT CHARSET=latin1
SELECT * FROM t6 ORDER BY a,b,c;
c a b
NULL 1 2
NULL 2 4
NULL 3 6
NULL 4 2
NULL 5 10
NULL 6 12
**** Resetting master and slave ****
include/stop_slave.inc
RESET SLAVE;
RESET MASTER;
include/start_slave.inc
CREATE TABLE t7 (UNIQUE(b)) SELECT a,b FROM tt3;
ERROR 23000: Duplicate entry '2' for key 'b'
SHOW BINLOG EVENTS FROM 107;
Log_name Pos Event_type Server_id End_log_pos Info
CREATE TABLE t7 (a INT, b INT UNIQUE);
INSERT INTO t7 SELECT a,b FROM tt3;
ERROR 23000: Duplicate entry '2' for key 'b'
SELECT * FROM t7 ORDER BY a,b;
a b
1 2
2 4
3 6
SHOW BINLOG EVENTS FROM 107;
Log_name Pos Event_type Server_id End_log_pos Info
# 107 Query # 207 use `test`; CREATE TABLE t7 (a INT, b INT UNIQUE)
# 207 Query # 275 BEGIN
# 275 Table_map # 317 table_id: # (test.t7)
# 317 Write_rows # 373 table_id: # flags: STMT_END_F
# 373 Query # 442 COMMIT
SELECT * FROM t7 ORDER BY a,b;
a b
1 2
2 4
3 6
**** Resetting master and slave ****
include/stop_slave.inc
RESET SLAVE;
RESET MASTER;
include/start_slave.inc
CREATE TEMPORARY TABLE tt4 (a INT, b INT);
INSERT INTO tt4 VALUES (4,8), (5,10), (6,12);
BEGIN;
INSERT INTO t7 SELECT a,b FROM tt4;
ROLLBACK;
Warnings:
Warning 1196 Some non-transactional changed tables couldn't be rolled back
SHOW BINLOG EVENTS FROM 107;
Log_name Pos Event_type Server_id End_log_pos Info
# 107 Query # 175 BEGIN
# 175 Table_map # 217 table_id: # (test.t7)
# 217 Write_rows # 273 table_id: # flags: STMT_END_F
# 273 Query # 342 COMMIT
SELECT * FROM t7 ORDER BY a,b;
a b
1 2
2 4
3 6
4 8
5 10
6 12
SELECT * FROM t7 ORDER BY a,b;
a b
1 2
2 4
3 6
4 8
5 10
6 12
**** Resetting master and slave ****
include/stop_slave.inc
RESET SLAVE;
RESET MASTER;
include/start_slave.inc
CREATE TABLE t8 LIKE t4;
CREATE TABLE t9 LIKE tt4;
CREATE TEMPORARY TABLE tt5 LIKE t4;
CREATE TEMPORARY TABLE tt6 LIKE tt4;
CREATE TEMPORARY TABLE tt7 SELECT 1;
**** On Master ****
SHOW CREATE TABLE t8;
Table t8
Create Table CREATE TABLE `t8` (
2006-03-06 20:12:48 +01:00
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
2008-03-14 21:37:19 +01:00
) ENGINE=MRG_MyISAM DEFAULT CHARSET=utf8
SHOW CREATE TABLE t9;
Table t9
Create Table CREATE TABLE `t9` (
2006-03-06 20:12:48 +01:00
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
SHOW BINLOG EVENTS FROM 107;
Log_name Pos Event_type Server_id End_log_pos Info
# 107 Query # 193 use `test`; CREATE TABLE t8 LIKE t4
# 193 Query # 332 use `test`; CREATE TABLE `t9` (
2006-03-06 20:12:48 +01:00
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
)
**** On Slave ****
SHOW CREATE TABLE t8;
Table t8
Create Table CREATE TABLE `t8` (
2006-03-06 20:12:48 +01:00
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
2008-03-14 21:37:19 +01:00
) ENGINE=MRG_MyISAM DEFAULT CHARSET=utf8
SHOW CREATE TABLE t9;
Table t9
Create Table CREATE TABLE `t9` (
2006-03-06 20:12:48 +01:00
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL
) ENGINE=MEMORY DEFAULT CHARSET=latin1
BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' from log): When row-based logging is used, the CREATE-SELECT is written as two parts: as a CREATE TABLE statement and as the rows for the table. For both transactional and non-transactional tables, the CREATE TABLE statement was written to the transaction cache, as were the rows, and on statement end, the entire transaction cache was written to the binary log if the table was non-transactional. For transactional tables, the events were kept in the transaction cache until end of transaction (or statement that were not part of a transaction). For the case when AUTOCOMMIT=0 and we are creating a transactional table using a create select, we would then keep the CREATE TABLE statement and the rows for the CREATE-SELECT, while executing the following statements. On a rollback, the transaction cache would then be cleared, which would also remove the CREATE TABLE statement. Hence no table would be created on the slave, while there is an empty table on the master. This relates to BUG#22865 where the table being created exists on the master, but not on the slave during insertion of rows into the newly created table. This occurs since the CREATE TABLE statement were still in the transaction cache until the statement finished executing, and possibly longer if the table was transactional. This patch changes the behaviour of the CREATE-SELECT statement by adding an implicit commit at the end of the statement when creating non-temporary tables. Hence, non-temporary tables will be written to the binary log on completion, and in the even of AUTOCOMMIT=0, a new transaction will be started. Temporary tables do not commit an ongoing transaction: neither as a pre- not a post-commit. The events for both transactional and non-transactional tables are saved in the transaction cache, and written to the binary log at end of the statement.
2006-12-21 09:29:02 +01:00
DROP TABLE IF EXISTS t1,t2,t3,t4,t5,t6,t7,t8,t9;
STOP SLAVE;
SET GLOBAL storage_engine=@storage_engine;
START SLAVE;
================ BUG#22864 ================
STOP SLAVE;
RESET SLAVE;
RESET MASTER;
START SLAVE;
SET AUTOCOMMIT=0;
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1),(2),(3);
CREATE TABLE t2 ENGINE=INNODB SELECT * FROM t1;
ROLLBACK;
CREATE TABLE t3 ENGINE=INNODB SELECT * FROM t1;
INSERT INTO t3 VALUES (4),(5),(6);
ROLLBACK;
CREATE TABLE t4 ENGINE=INNODB SELECT * FROM t1;
INSERT INTO t1 VALUES (4),(5),(6);
ROLLBACK;
Warnings:
Warning 1196 Some non-transactional changed tables couldn't be rolled back
SHOW TABLES;
Tables_in_test
t1
t2
t3
t4
SELECT TABLE_NAME,ENGINE
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE 't_'
ORDER BY TABLE_NAME;
TABLE_NAME ENGINE
t1 MyISAM
t2 InnoDB
t3 InnoDB
t4 InnoDB
SELECT * FROM t1 ORDER BY a;
a
1
2
3
4
5
6
SELECT * FROM t2 ORDER BY a;
a
1
2
3
SELECT * FROM t3 ORDER BY a;
a
1
2
3
SELECT * FROM t4 ORDER BY a;
a
1
2
3
SHOW BINLOG EVENTS FROM 107;
BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' from log): When row-based logging is used, the CREATE-SELECT is written as two parts: as a CREATE TABLE statement and as the rows for the table. For both transactional and non-transactional tables, the CREATE TABLE statement was written to the transaction cache, as were the rows, and on statement end, the entire transaction cache was written to the binary log if the table was non-transactional. For transactional tables, the events were kept in the transaction cache until end of transaction (or statement that were not part of a transaction). For the case when AUTOCOMMIT=0 and we are creating a transactional table using a create select, we would then keep the CREATE TABLE statement and the rows for the CREATE-SELECT, while executing the following statements. On a rollback, the transaction cache would then be cleared, which would also remove the CREATE TABLE statement. Hence no table would be created on the slave, while there is an empty table on the master. This relates to BUG#22865 where the table being created exists on the master, but not on the slave during insertion of rows into the newly created table. This occurs since the CREATE TABLE statement were still in the transaction cache until the statement finished executing, and possibly longer if the table was transactional. This patch changes the behaviour of the CREATE-SELECT statement by adding an implicit commit at the end of the statement when creating non-temporary tables. Hence, non-temporary tables will be written to the binary log on completion, and in the even of AUTOCOMMIT=0, a new transaction will be started. Temporary tables do not commit an ongoing transaction: neither as a pre- not a post-commit. The events for both transactional and non-transactional tables are saved in the transaction cache, and written to the binary log at end of the statement.
2006-12-21 09:29:02 +01:00
Log_name Pos Event_type Server_id End_log_pos Info
# 107 Query # 193 use `test`; CREATE TABLE t1 (a INT)
# 193 Query # 261 BEGIN
# 261 Table_map # 302 table_id: # (test.t1)
# 302 Write_rows # 346 table_id: # flags: STMT_END_F
# 346 Query # 415 COMMIT
# 415 Query # 483 BEGIN
# 483 Query # 608 use `test`; CREATE TABLE `t2` (
BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' from log): When row-based logging is used, the CREATE-SELECT is written as two parts: as a CREATE TABLE statement and as the rows for the table. For both transactional and non-transactional tables, the CREATE TABLE statement was written to the transaction cache, as were the rows, and on statement end, the entire transaction cache was written to the binary log if the table was non-transactional. For transactional tables, the events were kept in the transaction cache until end of transaction (or statement that were not part of a transaction). For the case when AUTOCOMMIT=0 and we are creating a transactional table using a create select, we would then keep the CREATE TABLE statement and the rows for the CREATE-SELECT, while executing the following statements. On a rollback, the transaction cache would then be cleared, which would also remove the CREATE TABLE statement. Hence no table would be created on the slave, while there is an empty table on the master. This relates to BUG#22865 where the table being created exists on the master, but not on the slave during insertion of rows into the newly created table. This occurs since the CREATE TABLE statement were still in the transaction cache until the statement finished executing, and possibly longer if the table was transactional. This patch changes the behaviour of the CREATE-SELECT statement by adding an implicit commit at the end of the statement when creating non-temporary tables. Hence, non-temporary tables will be written to the binary log on completion, and in the even of AUTOCOMMIT=0, a new transaction will be started. Temporary tables do not commit an ongoing transaction: neither as a pre- not a post-commit. The events for both transactional and non-transactional tables are saved in the transaction cache, and written to the binary log at end of the statement.
2006-12-21 09:29:02 +01:00
`a` int(11) DEFAULT NULL
) ENGINE=InnoDB
# 608 Table_map # 649 table_id: # (test.t2)
# 649 Write_rows # 693 table_id: # flags: STMT_END_F
# 693 Xid # 720 COMMIT /* XID */
# 720 Query # 788 BEGIN
# 788 Query # 913 use `test`; CREATE TABLE `t3` (
BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' from log): When row-based logging is used, the CREATE-SELECT is written as two parts: as a CREATE TABLE statement and as the rows for the table. For both transactional and non-transactional tables, the CREATE TABLE statement was written to the transaction cache, as were the rows, and on statement end, the entire transaction cache was written to the binary log if the table was non-transactional. For transactional tables, the events were kept in the transaction cache until end of transaction (or statement that were not part of a transaction). For the case when AUTOCOMMIT=0 and we are creating a transactional table using a create select, we would then keep the CREATE TABLE statement and the rows for the CREATE-SELECT, while executing the following statements. On a rollback, the transaction cache would then be cleared, which would also remove the CREATE TABLE statement. Hence no table would be created on the slave, while there is an empty table on the master. This relates to BUG#22865 where the table being created exists on the master, but not on the slave during insertion of rows into the newly created table. This occurs since the CREATE TABLE statement were still in the transaction cache until the statement finished executing, and possibly longer if the table was transactional. This patch changes the behaviour of the CREATE-SELECT statement by adding an implicit commit at the end of the statement when creating non-temporary tables. Hence, non-temporary tables will be written to the binary log on completion, and in the even of AUTOCOMMIT=0, a new transaction will be started. Temporary tables do not commit an ongoing transaction: neither as a pre- not a post-commit. The events for both transactional and non-transactional tables are saved in the transaction cache, and written to the binary log at end of the statement.
2006-12-21 09:29:02 +01:00
`a` int(11) DEFAULT NULL
) ENGINE=InnoDB
# 913 Table_map # 954 table_id: # (test.t3)
# 954 Write_rows # 998 table_id: # flags: STMT_END_F
# 998 Xid # 1025 COMMIT /* XID */
# 1025 Query # 1093 BEGIN
# 1093 Query # 1218 use `test`; CREATE TABLE `t4` (
BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' from log): When row-based logging is used, the CREATE-SELECT is written as two parts: as a CREATE TABLE statement and as the rows for the table. For both transactional and non-transactional tables, the CREATE TABLE statement was written to the transaction cache, as were the rows, and on statement end, the entire transaction cache was written to the binary log if the table was non-transactional. For transactional tables, the events were kept in the transaction cache until end of transaction (or statement that were not part of a transaction). For the case when AUTOCOMMIT=0 and we are creating a transactional table using a create select, we would then keep the CREATE TABLE statement and the rows for the CREATE-SELECT, while executing the following statements. On a rollback, the transaction cache would then be cleared, which would also remove the CREATE TABLE statement. Hence no table would be created on the slave, while there is an empty table on the master. This relates to BUG#22865 where the table being created exists on the master, but not on the slave during insertion of rows into the newly created table. This occurs since the CREATE TABLE statement were still in the transaction cache until the statement finished executing, and possibly longer if the table was transactional. This patch changes the behaviour of the CREATE-SELECT statement by adding an implicit commit at the end of the statement when creating non-temporary tables. Hence, non-temporary tables will be written to the binary log on completion, and in the even of AUTOCOMMIT=0, a new transaction will be started. Temporary tables do not commit an ongoing transaction: neither as a pre- not a post-commit. The events for both transactional and non-transactional tables are saved in the transaction cache, and written to the binary log at end of the statement.
2006-12-21 09:29:02 +01:00
`a` int(11) DEFAULT NULL
) ENGINE=InnoDB
# 1218 Table_map # 1259 table_id: # (test.t4)
# 1259 Write_rows # 1303 table_id: # flags: STMT_END_F
# 1303 Xid # 1330 COMMIT /* XID */
# 1330 Query # 1398 BEGIN
# 1398 Table_map # 1439 table_id: # (test.t1)
# 1439 Write_rows # 1483 table_id: # flags: STMT_END_F
# 1483 Query # 1552 COMMIT
BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' from log): When row-based logging is used, the CREATE-SELECT is written as two parts: as a CREATE TABLE statement and as the rows for the table. For both transactional and non-transactional tables, the CREATE TABLE statement was written to the transaction cache, as were the rows, and on statement end, the entire transaction cache was written to the binary log if the table was non-transactional. For transactional tables, the events were kept in the transaction cache until end of transaction (or statement that were not part of a transaction). For the case when AUTOCOMMIT=0 and we are creating a transactional table using a create select, we would then keep the CREATE TABLE statement and the rows for the CREATE-SELECT, while executing the following statements. On a rollback, the transaction cache would then be cleared, which would also remove the CREATE TABLE statement. Hence no table would be created on the slave, while there is an empty table on the master. This relates to BUG#22865 where the table being created exists on the master, but not on the slave during insertion of rows into the newly created table. This occurs since the CREATE TABLE statement were still in the transaction cache until the statement finished executing, and possibly longer if the table was transactional. This patch changes the behaviour of the CREATE-SELECT statement by adding an implicit commit at the end of the statement when creating non-temporary tables. Hence, non-temporary tables will be written to the binary log on completion, and in the even of AUTOCOMMIT=0, a new transaction will be started. Temporary tables do not commit an ongoing transaction: neither as a pre- not a post-commit. The events for both transactional and non-transactional tables are saved in the transaction cache, and written to the binary log at end of the statement.
2006-12-21 09:29:02 +01:00
SHOW TABLES;
Tables_in_test
t1
t2
t3
t4
SELECT TABLE_NAME,ENGINE
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE 't_'
ORDER BY TABLE_NAME;
TABLE_NAME ENGINE
t1 MyISAM
t2 InnoDB
t3 InnoDB
t4 InnoDB
SELECT * FROM t1 ORDER BY a;
a
1
2
3
4
5
6
SELECT * FROM t2 ORDER BY a;
a
1
2
3
SELECT * FROM t3 ORDER BY a;
a
1
2
3
SELECT * FROM t4 ORDER BY a;
a
1
2
3
DROP TABLE IF EXISTS t1,t2,t3,t4;
SET AUTOCOMMIT=1;
STOP SLAVE;
RESET SLAVE;
RESET MASTER;
START SLAVE;
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1),(2),(3);
CREATE TABLE t2 (a INT) ENGINE=INNODB;
BEGIN;
INSERT INTO t2 SELECT a*a FROM t1;
CREATE TEMPORARY TABLE tt1
SELECT a+1 AS a
FROM t1
WHERE a MOD 2 = 1;
INSERT INTO t2 SELECT a+2 FROM tt1;
COMMIT;
SELECT * FROM t2 ORDER BY a;
a
1
4
4
6
9
SHOW BINLOG EVENTS FROM 107;
BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' from log): When row-based logging is used, the CREATE-SELECT is written as two parts: as a CREATE TABLE statement and as the rows for the table. For both transactional and non-transactional tables, the CREATE TABLE statement was written to the transaction cache, as were the rows, and on statement end, the entire transaction cache was written to the binary log if the table was non-transactional. For transactional tables, the events were kept in the transaction cache until end of transaction (or statement that were not part of a transaction). For the case when AUTOCOMMIT=0 and we are creating a transactional table using a create select, we would then keep the CREATE TABLE statement and the rows for the CREATE-SELECT, while executing the following statements. On a rollback, the transaction cache would then be cleared, which would also remove the CREATE TABLE statement. Hence no table would be created on the slave, while there is an empty table on the master. This relates to BUG#22865 where the table being created exists on the master, but not on the slave during insertion of rows into the newly created table. This occurs since the CREATE TABLE statement were still in the transaction cache until the statement finished executing, and possibly longer if the table was transactional. This patch changes the behaviour of the CREATE-SELECT statement by adding an implicit commit at the end of the statement when creating non-temporary tables. Hence, non-temporary tables will be written to the binary log on completion, and in the even of AUTOCOMMIT=0, a new transaction will be started. Temporary tables do not commit an ongoing transaction: neither as a pre- not a post-commit. The events for both transactional and non-transactional tables are saved in the transaction cache, and written to the binary log at end of the statement.
2006-12-21 09:29:02 +01:00
Log_name Pos Event_type Server_id End_log_pos Info
# 107 Query # 193 use `test`; CREATE TABLE t1 (a INT)
# 193 Query # 261 BEGIN
# 261 Table_map # 302 table_id: # (test.t1)
# 302 Write_rows # 346 table_id: # flags: STMT_END_F
# 346 Query # 415 COMMIT
# 415 Query # 515 use `test`; CREATE TABLE t2 (a INT) ENGINE=INNODB
# 515 Query # 583 BEGIN
# 583 Table_map # 624 table_id: # (test.t2)
# 624 Write_rows # 668 table_id: # flags: STMT_END_F
# 668 Table_map # 709 table_id: # (test.t2)
# 709 Write_rows # 748 table_id: # flags: STMT_END_F
# 748 Xid # 775 COMMIT /* XID */
BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' from log): When row-based logging is used, the CREATE-SELECT is written as two parts: as a CREATE TABLE statement and as the rows for the table. For both transactional and non-transactional tables, the CREATE TABLE statement was written to the transaction cache, as were the rows, and on statement end, the entire transaction cache was written to the binary log if the table was non-transactional. For transactional tables, the events were kept in the transaction cache until end of transaction (or statement that were not part of a transaction). For the case when AUTOCOMMIT=0 and we are creating a transactional table using a create select, we would then keep the CREATE TABLE statement and the rows for the CREATE-SELECT, while executing the following statements. On a rollback, the transaction cache would then be cleared, which would also remove the CREATE TABLE statement. Hence no table would be created on the slave, while there is an empty table on the master. This relates to BUG#22865 where the table being created exists on the master, but not on the slave during insertion of rows into the newly created table. This occurs since the CREATE TABLE statement were still in the transaction cache until the statement finished executing, and possibly longer if the table was transactional. This patch changes the behaviour of the CREATE-SELECT statement by adding an implicit commit at the end of the statement when creating non-temporary tables. Hence, non-temporary tables will be written to the binary log on completion, and in the even of AUTOCOMMIT=0, a new transaction will be started. Temporary tables do not commit an ongoing transaction: neither as a pre- not a post-commit. The events for both transactional and non-transactional tables are saved in the transaction cache, and written to the binary log at end of the statement.
2006-12-21 09:29:02 +01:00
SELECT * FROM t2 ORDER BY a;
a
1
4
4
6
9
TRUNCATE TABLE t2;
**** Resetting master and slave ****
include/stop_slave.inc
RESET SLAVE;
RESET MASTER;
include/start_slave.inc
BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' from log): When row-based logging is used, the CREATE-SELECT is written as two parts: as a CREATE TABLE statement and as the rows for the table. For both transactional and non-transactional tables, the CREATE TABLE statement was written to the transaction cache, as were the rows, and on statement end, the entire transaction cache was written to the binary log if the table was non-transactional. For transactional tables, the events were kept in the transaction cache until end of transaction (or statement that were not part of a transaction). For the case when AUTOCOMMIT=0 and we are creating a transactional table using a create select, we would then keep the CREATE TABLE statement and the rows for the CREATE-SELECT, while executing the following statements. On a rollback, the transaction cache would then be cleared, which would also remove the CREATE TABLE statement. Hence no table would be created on the slave, while there is an empty table on the master. This relates to BUG#22865 where the table being created exists on the master, but not on the slave during insertion of rows into the newly created table. This occurs since the CREATE TABLE statement were still in the transaction cache until the statement finished executing, and possibly longer if the table was transactional. This patch changes the behaviour of the CREATE-SELECT statement by adding an implicit commit at the end of the statement when creating non-temporary tables. Hence, non-temporary tables will be written to the binary log on completion, and in the even of AUTOCOMMIT=0, a new transaction will be started. Temporary tables do not commit an ongoing transaction: neither as a pre- not a post-commit. The events for both transactional and non-transactional tables are saved in the transaction cache, and written to the binary log at end of the statement.
2006-12-21 09:29:02 +01:00
BEGIN;
INSERT INTO t2 SELECT a*a FROM t1;
CREATE TEMPORARY TABLE tt2
SELECT a+1 AS a
FROM t1
WHERE a MOD 2 = 1;
INSERT INTO t2 SELECT a+2 FROM tt2;
ROLLBACK;
Warnings:
Warning 1196 Some non-transactional changed tables couldn't be rolled back
BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' from log): When row-based logging is used, the CREATE-SELECT is written as two parts: as a CREATE TABLE statement and as the rows for the table. For both transactional and non-transactional tables, the CREATE TABLE statement was written to the transaction cache, as were the rows, and on statement end, the entire transaction cache was written to the binary log if the table was non-transactional. For transactional tables, the events were kept in the transaction cache until end of transaction (or statement that were not part of a transaction). For the case when AUTOCOMMIT=0 and we are creating a transactional table using a create select, we would then keep the CREATE TABLE statement and the rows for the CREATE-SELECT, while executing the following statements. On a rollback, the transaction cache would then be cleared, which would also remove the CREATE TABLE statement. Hence no table would be created on the slave, while there is an empty table on the master. This relates to BUG#22865 where the table being created exists on the master, but not on the slave during insertion of rows into the newly created table. This occurs since the CREATE TABLE statement were still in the transaction cache until the statement finished executing, and possibly longer if the table was transactional. This patch changes the behaviour of the CREATE-SELECT statement by adding an implicit commit at the end of the statement when creating non-temporary tables. Hence, non-temporary tables will be written to the binary log on completion, and in the even of AUTOCOMMIT=0, a new transaction will be started. Temporary tables do not commit an ongoing transaction: neither as a pre- not a post-commit. The events for both transactional and non-transactional tables are saved in the transaction cache, and written to the binary log at end of the statement.
2006-12-21 09:29:02 +01:00
SELECT * FROM t2 ORDER BY a;
a
SHOW BINLOG EVENTS FROM 107;
BUG#22864 (Rollback following CREATE... SELECT discards 'CREATE TABLE' from log): When row-based logging is used, the CREATE-SELECT is written as two parts: as a CREATE TABLE statement and as the rows for the table. For both transactional and non-transactional tables, the CREATE TABLE statement was written to the transaction cache, as were the rows, and on statement end, the entire transaction cache was written to the binary log if the table was non-transactional. For transactional tables, the events were kept in the transaction cache until end of transaction (or statement that were not part of a transaction). For the case when AUTOCOMMIT=0 and we are creating a transactional table using a create select, we would then keep the CREATE TABLE statement and the rows for the CREATE-SELECT, while executing the following statements. On a rollback, the transaction cache would then be cleared, which would also remove the CREATE TABLE statement. Hence no table would be created on the slave, while there is an empty table on the master. This relates to BUG#22865 where the table being created exists on the master, but not on the slave during insertion of rows into the newly created table. This occurs since the CREATE TABLE statement were still in the transaction cache until the statement finished executing, and possibly longer if the table was transactional. This patch changes the behaviour of the CREATE-SELECT statement by adding an implicit commit at the end of the statement when creating non-temporary tables. Hence, non-temporary tables will be written to the binary log on completion, and in the even of AUTOCOMMIT=0, a new transaction will be started. Temporary tables do not commit an ongoing transaction: neither as a pre- not a post-commit. The events for both transactional and non-transactional tables are saved in the transaction cache, and written to the binary log at end of the statement.
2006-12-21 09:29:02 +01:00
Log_name Pos Event_type Server_id End_log_pos Info
SELECT * FROM t2 ORDER BY a;
a
DROP TABLE t1,t2;
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1),(1);
CREATE TABLE t2 (a INT UNIQUE) ENGINE=INNODB SELECT * FROM t1;
ERROR 23000: Duplicate entry '1' for key 'a'
INSERT INTO t1 VALUES (2);
*** the proof of the fix:
select must show that the last insert performed on the slave ***
SELECT * FROM t1;
a
1
1
2
DROP TABLE t1;
stop slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
reset master;
reset slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
start slave;
DROP DATABASE IF EXISTS mysqltest1;
CREATE DATABASE mysqltest1;
CREATE TABLE mysqltest1.without_select (f1 BIGINT);
CREATE TABLE mysqltest1.with_select AS SELECT 1 AS f1;
show binlog events from <binlog_start>;
Log_name Pos Event_type Server_id End_log_pos Info
master-bin.000001 # Query # # DROP DATABASE IF EXISTS mysqltest1
master-bin.000001 # Query # # CREATE DATABASE mysqltest1
master-bin.000001 # Query # # use `test`; CREATE TABLE mysqltest1.without_select (f1 BIGINT)
master-bin.000001 # Query # # BEGIN
master-bin.000001 # Query # # use `test`; CREATE TABLE `mysqltest1`.`with_select` (
`f1` int(1) NOT NULL DEFAULT '0'
)
master-bin.000001 # Table_map # # table_id: # (mysqltest1.with_select)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
master-bin.000001 # Query # # COMMIT
DROP DATABASE mysqltest1;
end of the tests