mariadb/mysql-test/t/mix_innodb_myisam_binlog.test

571 lines
13 KiB
Text
Raw Normal View History

2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
# Check that binlog is ok when a transaction mixes updates to InnoDB and
# MyISAM.
# It would be nice to make this a replication test, but in 4.0 the
# slave is always with --skip-innodb in the testsuite. I (Guilhem) however
# did some tests manually on a slave; tables are replicated fine and
Write slave status field names using consistent style. (Initial caps for each word.) For example, instead of writing Until_condition, Until_Log_File, and Until_log_pos, write Until_Condition, Until_Log_File, and Until_Log_pos. mysql-test/r/rpl000015.result: Write slave status field names using consistent style. mysql-test/r/rpl_empty_master_crash.result: Write slave status field names using consistent style. mysql-test/r/rpl_error_ignored_table.result: Write slave status field names using consistent style. mysql-test/r/rpl_flush_log_loop.result: Write slave status field names using consistent style. mysql-test/r/rpl_loaddata.result: Write slave status field names using consistent style. mysql-test/r/rpl_log.result: Write slave status field names using consistent style. mysql-test/r/rpl_log_pos.result: Write slave status field names using consistent style. mysql-test/r/rpl_max_relay_size.result: Write slave status field names using consistent style. mysql-test/r/rpl_openssl.result: Write slave status field names using consistent style. mysql-test/r/rpl_redirect.result: Write slave status field names using consistent style. mysql-test/r/rpl_replicate_do.result: Write slave status field names using consistent style. mysql-test/r/rpl_reset_slave.result: Write slave status field names using consistent style. mysql-test/r/rpl_rotate_logs.result: Write slave status field names using consistent style. mysql-test/r/rpl_trunc_binlog.result: Write slave status field names using consistent style. mysql-test/r/rpl_until.result: Write slave status field names using consistent style. mysql-test/t/mix_innodb_myisam_binlog.test: Write slave status field names using consistent style. mysql-test/t/rpl_max_relay_size.test: Write slave status field names using consistent style. sql/slave.cc: Write slave status field names using consistent style.
2003-11-20 20:07:25 +01:00
# Exec_Master_Log_Pos advances as expected.
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
Bug#28369 rpl test cases fail with binlog disabled - Turn on binlog only for tests that need it - Skip those tests if --skip-binlog is used BitKeeper/deleted/.del-ctype_cp932_notembedded.result: Rename: mysql-test/r/ctype_cp932_notembedded.result -> BitKeeper/deleted/.del-ctype_cp932_notembedded.result BitKeeper/deleted/.del-ctype_cp932_notembedded.test: Rename: mysql-test/t/ctype_cp932_notembedded.test -> BitKeeper/deleted/.del-ctype_cp932_notembedded.test mysql-test/include/master-slave.inc: Need binlog mysql-test/lib/mtr_cases.pl: Turn on binlog only for tests that need it Skip those tests if --skip-binlog is used mysql-test/r/sp_trans.result: Moved to "sp_binlog" mysql-test/t/binlog.test: Need binlog mysql-test/t/blackhole.test: Need binlog mysql-test/t/ctype_cp932_binlog.test: Need binlog mysql-test/t/ctype_ucs_binlog.test: Need binlog mysql-test/t/drop_temp_table.test: Need binlog mysql-test/t/flush_block_commit_notembedded.test: Need binlog mysql-test/t/innodb.test: Need binlog mysql-test/t/insert_select-binlog.test: Need binlog mysql-test/t/mix_innodb_myisam_binlog.test: Need binlog mysql-test/t/mysqlbinlog-cp932.test: Need binlog mysql-test/t/mysqlbinlog.test: Need binlog mysql-test/t/mysqlbinlog2.test: Need binlog mysql-test/t/mysqldump.test: Need binlog mysql-test/t/rpl000015.test: Need binlog mysql-test/t/rpl000017.test: Need binlog mysql-test/t/rpl_rotate_logs.test: Need binlog mysql-test/t/sp_trans.test: Moved to "sp_binlog" mysql-test/t/user_var-binlog.test: Need binlog mysql-test/r/sp_trans_log.result: New BitKeeper file ``mysql-test/r/sp_trans_log.result'' mysql-test/t/sp_trans_log.test: New BitKeeper file ``mysql-test/t/sp_trans_log.test''
2007-06-07 19:18:01 +02:00
-- source include/have_log_bin.inc
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
-- source include/have_innodb.inc
--disable_warnings
drop table if exists t1, t2;
--enable_warnings
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
connect (con1,localhost,root,,);
connect (con2,localhost,root,,);
connection con1;
WorkLog#1323 Deprecate the use of TYPE=... Preferred syntax is ENGINE= include/mysqld_error.h: New warning for deprecated syntax sql/lex.h: Introduce ENGINE keyword Sort order of symbols sql/share/czech/errmsg.txt: New warning for deprecated syntax sql/share/danish/errmsg.txt: New warning for deprecated syntax sql/share/dutch/errmsg.txt: New warning for deprecated syntax sql/share/english/errmsg.txt: New warning for deprecated syntax sql/share/estonian/errmsg.txt: New warning for deprecated syntax sql/share/french/errmsg.txt: New warning for deprecated syntax sql/share/german/errmsg.txt: New warning for deprecated syntax sql/share/greek/errmsg.txt: New warning for deprecated syntax sql/share/hungarian/errmsg.txt: New warning for deprecated syntax sql/share/italian/errmsg.txt: New warning for deprecated syntax sql/share/japanese/errmsg.txt: New warning for deprecated syntax sql/share/korean/errmsg.txt: New warning for deprecated syntax sql/share/norwegian-ny/errmsg.txt: New warning for deprecated syntax sql/share/norwegian/errmsg.txt: New warning for deprecated syntax sql/share/polish/errmsg.txt: New warning for deprecated syntax sql/share/portuguese/errmsg.txt: New warning for deprecated syntax sql/share/romanian/errmsg.txt: New warning for deprecated syntax sql/share/russian/errmsg.txt: New warning for deprecated syntax sql/share/serbian/errmsg.txt: New warning for deprecated syntax sql/share/slovak/errmsg.txt: New warning for deprecated syntax sql/share/spanish/errmsg.txt: New warning for deprecated syntax sql/share/swedish/errmsg.txt: New warning for deprecated syntax sql/share/ukrainian/errmsg.txt: New warning for deprecated syntax sql/sql_show.cc: Change TYPE= with ENGINE= sql/sql_yacc.yy: Introduce ENGINE keyword, Deprecate TYPE= syntax, Introduce SHOW ENGINE syntax, Deprecate SHOW INNODB/BDB syntax. mysql-test/r/alias.result: Change occurances of TYPE= to ENGINE= mysql-test/r/alter_table.result: Change occurances of TYPE= to ENGINE= mysql-test/r/auto_increment.result: Change occurances of TYPE= to ENGINE= mysql-test/r/bdb-alter-table-1.result: Change occurances of TYPE= to ENGINE= mysql-test/r/bdb-crash.result: Change occurances of TYPE= to ENGINE= mysql-test/r/bdb-deadlock.result: Change occurances of TYPE= to ENGINE= mysql-test/r/bdb.result: Change occurances of TYPE= to ENGINE= mysql-test/r/bdb_cache.result: Change occurances of TYPE= to ENGINE= mysql-test/r/case.result: Change occurances of TYPE= to ENGINE= mysql-test/r/cast.result: Change occurances of TYPE= to ENGINE= mysql-test/r/constraints.result: Change occurances of TYPE= to ENGINE= mysql-test/r/create.result: Change occurances of TYPE= to ENGINE= mysql-test/r/ctype_collate.result: Change occurances of TYPE= to ENGINE= mysql-test/r/ctype_latin1_de.result: Change occurances of TYPE= to ENGINE= mysql-test/r/ctype_many.result: Change occurances of TYPE= to ENGINE= mysql-test/r/ctype_mb.result: Change occurances of TYPE= to ENGINE= mysql-test/r/ctype_recoding.result: Change occurances of TYPE= to ENGINE= mysql-test/r/ctype_ucs.result: Change occurances of TYPE= to ENGINE= mysql-test/r/delete.result: Change occurances of TYPE= to ENGINE= mysql-test/r/distinct.result: Change occurances of TYPE= to ENGINE= mysql-test/r/fulltext.result: Change occurances of TYPE= to ENGINE= mysql-test/r/fulltext2.result: Change occurances of TYPE= to ENGINE= mysql-test/r/fulltext_distinct.result: Change occurances of TYPE= to ENGINE= mysql-test/r/fulltext_left_join.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_compress.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_date_add.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_group.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_if.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_str.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_system.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_test.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_time.result: Change occurances of TYPE= to ENGINE= mysql-test/r/gis-rtree.result: Change occurances of TYPE= to ENGINE= mysql-test/r/group_by.result: Change occurances of TYPE= to ENGINE= mysql-test/r/handler.result: Change occurances of TYPE= to ENGINE= mysql-test/r/heap.result: Change occurances of TYPE= to ENGINE= mysql-test/r/heap_auto_increment.result: Change occurances of TYPE= to ENGINE= mysql-test/r/heap_btree.result: Change occurances of TYPE= to ENGINE= mysql-test/r/heap_hash.result: Change occurances of TYPE= to ENGINE= mysql-test/r/help.result: Change occurances of TYPE= to ENGINE= mysql-test/r/innodb-deadlock.result: Change occurances of TYPE= to ENGINE= mysql-test/r/innodb.result: Change occurances of TYPE= to ENGINE= mysql-test/r/innodb_cache.result: Change occurances of TYPE= to ENGINE= mysql-test/r/innodb_handler.result: Change occurances of TYPE= to ENGINE= mysql-test/r/insert_select.result: Change occurances of TYPE= to ENGINE= mysql-test/r/isam.result: Change occurances of TYPE= to ENGINE= mysql-test/r/join.result: Change occurances of TYPE= to ENGINE= mysql-test/r/join_crash.result: Change occurances of TYPE= to ENGINE= mysql-test/r/join_outer.result: Change occurances of TYPE= to ENGINE= mysql-test/r/key.result: Change occurances of TYPE= to ENGINE= mysql-test/r/lock.result: Change occurances of TYPE= to ENGINE= mysql-test/r/lock_tables_lost_commit.result: Change occurances of TYPE= to ENGINE= mysql-test/r/merge.result: Change occurances of TYPE= to ENGINE= mysql-test/r/mix_innodb_myisam_binlog.result: Change occurances of TYPE= to ENGINE= mysql-test/r/multi_update.result: Change occurances of TYPE= to ENGINE= mysql-test/r/myisam.result: Change occurances of TYPE= to ENGINE= mysql-test/r/null.result: Change occurances of TYPE= to ENGINE= mysql-test/r/null_key.result: Change occurances of TYPE= to ENGINE= mysql-test/r/order_by.result: Change occurances of TYPE= to ENGINE= mysql-test/r/query_cache.result: Change occurances of TYPE= to ENGINE= mysql-test/r/range.result: Change occurances of TYPE= to ENGINE= mysql-test/r/repair_part1.result: Change occurances of TYPE= to ENGINE= mysql-test/r/replace.result: Change occurances of TYPE= to ENGINE= mysql-test/r/rollback.result: Change occurances of TYPE= to ENGINE= mysql-test/r/rpl000006.result: Change occurances of TYPE= to ENGINE= mysql-test/r/rpl_flush_tables.result: Change occurances of TYPE= to ENGINE= mysql-test/r/rpl_insert_id.result: Change occurances of TYPE= to ENGINE= mysql-test/r/rpl_relayrotate.result: Change occurances of TYPE= to ENGINE= mysql-test/r/select.result: Change occurances of TYPE= to ENGINE= mysql-test/r/select_found.result: Change occurances of TYPE= to ENGINE= mysql-test/r/show_check.result: Change occurances of TYPE= to ENGINE= mysql-test/r/sql_mode.result: Change occurances of TYPE= to ENGINE= mysql-test/r/status.result: Change occurances of TYPE= to ENGINE= mysql-test/r/subselect.result: Change occurances of TYPE= to ENGINE= mysql-test/r/subselect2.result: Change occurances of TYPE= to ENGINE= mysql-test/r/subselect_innodb.result: Change occurances of TYPE= to ENGINE= mysql-test/r/symlink.result: Change occurances of TYPE= to ENGINE= mysql-test/r/temp_table.result: Change occurances of TYPE= to ENGINE= mysql-test/r/type_blob.result: Change occurances of TYPE= to ENGINE= mysql-test/r/type_datetime.result: Change occurances of TYPE= to ENGINE= mysql-test/r/type_enum.result: Change occurances of TYPE= to ENGINE= mysql-test/r/type_nchar.result: Change occurances of TYPE= to ENGINE= mysql-test/r/type_set.result: Change occurances of TYPE= to ENGINE= mysql-test/r/union.result: Change occurances of TYPE= to ENGINE= mysql-test/r/update.result: Change occurances of TYPE= to ENGINE= mysql-test/r/warnings.result: Change occurances of TYPE= to ENGINE= mysql-test/t/alias.test: Change occurances of TYPE= to ENGINE= mysql-test/t/alter_table.test: Change occurances of TYPE= to ENGINE= mysql-test/t/auto_increment.test: Change occurances of TYPE= to ENGINE= mysql-test/t/bdb-alter-table-1.test: Change occurances of TYPE= to ENGINE= mysql-test/t/bdb-crash.test: Change occurances of TYPE= to ENGINE= mysql-test/t/bdb-deadlock.test: Change occurances of TYPE= to ENGINE= mysql-test/t/bdb.test: Change occurances of TYPE= to ENGINE= mysql-test/t/bdb_cache.test: Change occurances of TYPE= to ENGINE= mysql-test/t/create.test: Change occurances of TYPE= to ENGINE= mysql-test/t/ctype_ucs.test: Change occurances of TYPE= to ENGINE= mysql-test/t/delete.test: Change occurances of TYPE= to ENGINE= mysql-test/t/distinct.test: Change occurances of TYPE= to ENGINE= mysql-test/t/fulltext.test: Change occurances of TYPE= to ENGINE= mysql-test/t/fulltext2.test: Change occurances of TYPE= to ENGINE= mysql-test/t/fulltext_distinct.test: Change occurances of TYPE= to ENGINE= mysql-test/t/fulltext_left_join.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_compress.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_date_add.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_group.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_if.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_str.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_test.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_time.test: Change occurances of TYPE= to ENGINE= mysql-test/t/gis-rtree.test: Change occurances of TYPE= to ENGINE= mysql-test/t/group_by.test: Change occurances of TYPE= to ENGINE= mysql-test/t/handler.test: Change occurances of TYPE= to ENGINE= mysql-test/t/heap.test: Change occurances of TYPE= to ENGINE= mysql-test/t/heap_auto_increment.test: Change occurances of TYPE= to ENGINE= mysql-test/t/heap_btree.test: Change occurances of TYPE= to ENGINE= mysql-test/t/heap_hash.test: Change occurances of TYPE= to ENGINE= mysql-test/t/help.test: Change occurances of TYPE= to ENGINE= mysql-test/t/innodb-deadlock.test: Change occurances of TYPE= to ENGINE= mysql-test/t/innodb.test: Change occurances of TYPE= to ENGINE= mysql-test/t/innodb_cache.test: Change occurances of TYPE= to ENGINE= mysql-test/t/innodb_handler.test: Change occurances of TYPE= to ENGINE= mysql-test/t/insert_select.test: Change occurances of TYPE= to ENGINE= mysql-test/t/isam.test: Change occurances of TYPE= to ENGINE= mysql-test/t/join.test: Change occurances of TYPE= to ENGINE= mysql-test/t/join_crash.test: Change occurances of TYPE= to ENGINE= mysql-test/t/join_outer.test: Change occurances of TYPE= to ENGINE= mysql-test/t/key.test: Change occurances of TYPE= to ENGINE= mysql-test/t/lock.test: Change occurances of TYPE= to ENGINE= mysql-test/t/lock_tables_lost_commit.test: Change occurances of TYPE= to ENGINE= mysql-test/t/merge.test: Change occurances of TYPE= to ENGINE= mysql-test/t/mix_innodb_myisam_binlog.test: Change occurances of TYPE= to ENGINE= mysql-test/t/multi_update.test: Change occurances of TYPE= to ENGINE= mysql-test/t/myisam.test: Change occurances of TYPE= to ENGINE= mysql-test/t/null.test: Change occurances of TYPE= to ENGINE= mysql-test/t/null_key.test: Change occurances of TYPE= to ENGINE= mysql-test/t/order_by.test: Change occurances of TYPE= to ENGINE= mysql-test/t/outfile.test: Change occurances of TYPE= to ENGINE= mysql-test/t/query_cache.test: Change occurances of TYPE= to ENGINE= mysql-test/t/query_cache_merge.test: Change occurances of TYPE= to ENGINE= mysql-test/t/range.test: Change occurances of TYPE= to ENGINE= mysql-test/t/repair_part1.test: Change occurances of TYPE= to ENGINE= mysql-test/t/replace.test: Change occurances of TYPE= to ENGINE= mysql-test/t/rollback.test: Change occurances of TYPE= to ENGINE= mysql-test/t/rpl000006.test: Change occurances of TYPE= to ENGINE= mysql-test/t/rpl_flush_tables.test: Change occurances of TYPE= to ENGINE= mysql-test/t/rpl_insert_id.test: Change occurances of TYPE= to ENGINE= mysql-test/t/rpl_relayrotate.test: Change occurances of TYPE= to ENGINE= mysql-test/t/select.test: Change occurances of TYPE= to ENGINE= mysql-test/t/select_found.test: Change occurances of TYPE= to ENGINE= mysql-test/t/show_check.test: Change occurances of TYPE= to ENGINE= mysql-test/t/sql_mode.test: Change occurances of TYPE= to ENGINE= mysql-test/t/status.test: Change occurances of TYPE= to ENGINE= mysql-test/t/subselect.test: Change occurances of TYPE= to ENGINE= mysql-test/t/subselect2.test: Change occurances of TYPE= to ENGINE= mysql-test/t/subselect_innodb.test: Change occurances of TYPE= to ENGINE= mysql-test/t/symlink.test: Change occurances of TYPE= to ENGINE= mysql-test/t/temp_table.test: Change occurances of TYPE= to ENGINE= mysql-test/t/type_datetime.test: Change occurances of TYPE= to ENGINE= mysql-test/t/type_set.test: Change occurances of TYPE= to ENGINE= mysql-test/t/union.test: Change occurances of TYPE= to ENGINE= mysql-test/t/update.test: Change occurances of TYPE= to ENGINE= mysql-test/t/warnings.test: Change occurances of TYPE= to ENGINE= New test for deprecated syntax
2003-12-10 05:31:42 +01:00
create table t1 (a int) engine=innodb;
create table t2 (a int) engine=myisam;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
reset master;
begin;
insert into t1 values(1);
insert into t2 select * from t1;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
commit;
source include/show_binlog_events.inc;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
delete from t1;
delete from t2;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
reset master;
begin;
insert into t1 values(2);
insert into t2 select * from t1;
# should say some changes to non-transact1onal tables couldn't be rolled back
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
rollback;
source include/show_binlog_events.inc;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
delete from t1;
delete from t2;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
reset master;
begin;
insert into t1 values(3);
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
savepoint my_savepoint;
insert into t1 values(4);
insert into t2 select * from t1;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
rollback to savepoint my_savepoint;
commit;
source include/show_binlog_events.inc;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
delete from t1;
delete from t2;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
reset master;
begin;
insert into t1 values(5);
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
savepoint my_savepoint;
insert into t1 values(6);
insert into t2 select * from t1;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
rollback to savepoint my_savepoint;
insert into t1 values(7);
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
commit;
select a from t1 order by a; # check that savepoints work :)
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
source include/show_binlog_events.inc;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
# and when ROLLBACK is not explicit?
delete from t1;
delete from t2;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
reset master;
select get_lock("a",10);
begin;
insert into t1 values(8);
insert into t2 select * from t1;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
disconnect con1;
connection con2;
# We want to SHOW BINLOG EVENTS, to know what was logged. But there is no
# guarantee that logging of the terminated con1 has been done yet (it may not
# even be started, so con1 may have not even attempted to lock the binlog yet;
# so SHOW BINLOG EVENTS may come before con1 does the loggin. To be sure that
# logging has been done, we use a user lock.
select get_lock("a",10);
source include/show_binlog_events.inc;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
# and when not in a transact1on?
delete from t1;
delete from t2;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
reset master;
insert into t1 values(9);
insert into t2 select * from t1;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
source include/show_binlog_events.inc;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
# Check that when the query updat1ng the MyISAM table is the first in the
# transaction, we log it immediately.
delete from t1;
delete from t2;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
reset master;
insert into t1 values(10); # first make t1 non-empty
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
begin;
insert into t2 select * from t1;
source include/show_binlog_events.inc;
insert into t1 values(11);
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
commit;
source include/show_binlog_events.inc;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
# Check that things work like before this BEGIN/ROLLBACK code was added,
# when t2 is INNODB
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
WorkLog#1323 Deprecate the use of TYPE=... Preferred syntax is ENGINE= include/mysqld_error.h: New warning for deprecated syntax sql/lex.h: Introduce ENGINE keyword Sort order of symbols sql/share/czech/errmsg.txt: New warning for deprecated syntax sql/share/danish/errmsg.txt: New warning for deprecated syntax sql/share/dutch/errmsg.txt: New warning for deprecated syntax sql/share/english/errmsg.txt: New warning for deprecated syntax sql/share/estonian/errmsg.txt: New warning for deprecated syntax sql/share/french/errmsg.txt: New warning for deprecated syntax sql/share/german/errmsg.txt: New warning for deprecated syntax sql/share/greek/errmsg.txt: New warning for deprecated syntax sql/share/hungarian/errmsg.txt: New warning for deprecated syntax sql/share/italian/errmsg.txt: New warning for deprecated syntax sql/share/japanese/errmsg.txt: New warning for deprecated syntax sql/share/korean/errmsg.txt: New warning for deprecated syntax sql/share/norwegian-ny/errmsg.txt: New warning for deprecated syntax sql/share/norwegian/errmsg.txt: New warning for deprecated syntax sql/share/polish/errmsg.txt: New warning for deprecated syntax sql/share/portuguese/errmsg.txt: New warning for deprecated syntax sql/share/romanian/errmsg.txt: New warning for deprecated syntax sql/share/russian/errmsg.txt: New warning for deprecated syntax sql/share/serbian/errmsg.txt: New warning for deprecated syntax sql/share/slovak/errmsg.txt: New warning for deprecated syntax sql/share/spanish/errmsg.txt: New warning for deprecated syntax sql/share/swedish/errmsg.txt: New warning for deprecated syntax sql/share/ukrainian/errmsg.txt: New warning for deprecated syntax sql/sql_show.cc: Change TYPE= with ENGINE= sql/sql_yacc.yy: Introduce ENGINE keyword, Deprecate TYPE= syntax, Introduce SHOW ENGINE syntax, Deprecate SHOW INNODB/BDB syntax. mysql-test/r/alias.result: Change occurances of TYPE= to ENGINE= mysql-test/r/alter_table.result: Change occurances of TYPE= to ENGINE= mysql-test/r/auto_increment.result: Change occurances of TYPE= to ENGINE= mysql-test/r/bdb-alter-table-1.result: Change occurances of TYPE= to ENGINE= mysql-test/r/bdb-crash.result: Change occurances of TYPE= to ENGINE= mysql-test/r/bdb-deadlock.result: Change occurances of TYPE= to ENGINE= mysql-test/r/bdb.result: Change occurances of TYPE= to ENGINE= mysql-test/r/bdb_cache.result: Change occurances of TYPE= to ENGINE= mysql-test/r/case.result: Change occurances of TYPE= to ENGINE= mysql-test/r/cast.result: Change occurances of TYPE= to ENGINE= mysql-test/r/constraints.result: Change occurances of TYPE= to ENGINE= mysql-test/r/create.result: Change occurances of TYPE= to ENGINE= mysql-test/r/ctype_collate.result: Change occurances of TYPE= to ENGINE= mysql-test/r/ctype_latin1_de.result: Change occurances of TYPE= to ENGINE= mysql-test/r/ctype_many.result: Change occurances of TYPE= to ENGINE= mysql-test/r/ctype_mb.result: Change occurances of TYPE= to ENGINE= mysql-test/r/ctype_recoding.result: Change occurances of TYPE= to ENGINE= mysql-test/r/ctype_ucs.result: Change occurances of TYPE= to ENGINE= mysql-test/r/delete.result: Change occurances of TYPE= to ENGINE= mysql-test/r/distinct.result: Change occurances of TYPE= to ENGINE= mysql-test/r/fulltext.result: Change occurances of TYPE= to ENGINE= mysql-test/r/fulltext2.result: Change occurances of TYPE= to ENGINE= mysql-test/r/fulltext_distinct.result: Change occurances of TYPE= to ENGINE= mysql-test/r/fulltext_left_join.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_compress.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_date_add.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_group.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_if.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_str.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_system.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_test.result: Change occurances of TYPE= to ENGINE= mysql-test/r/func_time.result: Change occurances of TYPE= to ENGINE= mysql-test/r/gis-rtree.result: Change occurances of TYPE= to ENGINE= mysql-test/r/group_by.result: Change occurances of TYPE= to ENGINE= mysql-test/r/handler.result: Change occurances of TYPE= to ENGINE= mysql-test/r/heap.result: Change occurances of TYPE= to ENGINE= mysql-test/r/heap_auto_increment.result: Change occurances of TYPE= to ENGINE= mysql-test/r/heap_btree.result: Change occurances of TYPE= to ENGINE= mysql-test/r/heap_hash.result: Change occurances of TYPE= to ENGINE= mysql-test/r/help.result: Change occurances of TYPE= to ENGINE= mysql-test/r/innodb-deadlock.result: Change occurances of TYPE= to ENGINE= mysql-test/r/innodb.result: Change occurances of TYPE= to ENGINE= mysql-test/r/innodb_cache.result: Change occurances of TYPE= to ENGINE= mysql-test/r/innodb_handler.result: Change occurances of TYPE= to ENGINE= mysql-test/r/insert_select.result: Change occurances of TYPE= to ENGINE= mysql-test/r/isam.result: Change occurances of TYPE= to ENGINE= mysql-test/r/join.result: Change occurances of TYPE= to ENGINE= mysql-test/r/join_crash.result: Change occurances of TYPE= to ENGINE= mysql-test/r/join_outer.result: Change occurances of TYPE= to ENGINE= mysql-test/r/key.result: Change occurances of TYPE= to ENGINE= mysql-test/r/lock.result: Change occurances of TYPE= to ENGINE= mysql-test/r/lock_tables_lost_commit.result: Change occurances of TYPE= to ENGINE= mysql-test/r/merge.result: Change occurances of TYPE= to ENGINE= mysql-test/r/mix_innodb_myisam_binlog.result: Change occurances of TYPE= to ENGINE= mysql-test/r/multi_update.result: Change occurances of TYPE= to ENGINE= mysql-test/r/myisam.result: Change occurances of TYPE= to ENGINE= mysql-test/r/null.result: Change occurances of TYPE= to ENGINE= mysql-test/r/null_key.result: Change occurances of TYPE= to ENGINE= mysql-test/r/order_by.result: Change occurances of TYPE= to ENGINE= mysql-test/r/query_cache.result: Change occurances of TYPE= to ENGINE= mysql-test/r/range.result: Change occurances of TYPE= to ENGINE= mysql-test/r/repair_part1.result: Change occurances of TYPE= to ENGINE= mysql-test/r/replace.result: Change occurances of TYPE= to ENGINE= mysql-test/r/rollback.result: Change occurances of TYPE= to ENGINE= mysql-test/r/rpl000006.result: Change occurances of TYPE= to ENGINE= mysql-test/r/rpl_flush_tables.result: Change occurances of TYPE= to ENGINE= mysql-test/r/rpl_insert_id.result: Change occurances of TYPE= to ENGINE= mysql-test/r/rpl_relayrotate.result: Change occurances of TYPE= to ENGINE= mysql-test/r/select.result: Change occurances of TYPE= to ENGINE= mysql-test/r/select_found.result: Change occurances of TYPE= to ENGINE= mysql-test/r/show_check.result: Change occurances of TYPE= to ENGINE= mysql-test/r/sql_mode.result: Change occurances of TYPE= to ENGINE= mysql-test/r/status.result: Change occurances of TYPE= to ENGINE= mysql-test/r/subselect.result: Change occurances of TYPE= to ENGINE= mysql-test/r/subselect2.result: Change occurances of TYPE= to ENGINE= mysql-test/r/subselect_innodb.result: Change occurances of TYPE= to ENGINE= mysql-test/r/symlink.result: Change occurances of TYPE= to ENGINE= mysql-test/r/temp_table.result: Change occurances of TYPE= to ENGINE= mysql-test/r/type_blob.result: Change occurances of TYPE= to ENGINE= mysql-test/r/type_datetime.result: Change occurances of TYPE= to ENGINE= mysql-test/r/type_enum.result: Change occurances of TYPE= to ENGINE= mysql-test/r/type_nchar.result: Change occurances of TYPE= to ENGINE= mysql-test/r/type_set.result: Change occurances of TYPE= to ENGINE= mysql-test/r/union.result: Change occurances of TYPE= to ENGINE= mysql-test/r/update.result: Change occurances of TYPE= to ENGINE= mysql-test/r/warnings.result: Change occurances of TYPE= to ENGINE= mysql-test/t/alias.test: Change occurances of TYPE= to ENGINE= mysql-test/t/alter_table.test: Change occurances of TYPE= to ENGINE= mysql-test/t/auto_increment.test: Change occurances of TYPE= to ENGINE= mysql-test/t/bdb-alter-table-1.test: Change occurances of TYPE= to ENGINE= mysql-test/t/bdb-crash.test: Change occurances of TYPE= to ENGINE= mysql-test/t/bdb-deadlock.test: Change occurances of TYPE= to ENGINE= mysql-test/t/bdb.test: Change occurances of TYPE= to ENGINE= mysql-test/t/bdb_cache.test: Change occurances of TYPE= to ENGINE= mysql-test/t/create.test: Change occurances of TYPE= to ENGINE= mysql-test/t/ctype_ucs.test: Change occurances of TYPE= to ENGINE= mysql-test/t/delete.test: Change occurances of TYPE= to ENGINE= mysql-test/t/distinct.test: Change occurances of TYPE= to ENGINE= mysql-test/t/fulltext.test: Change occurances of TYPE= to ENGINE= mysql-test/t/fulltext2.test: Change occurances of TYPE= to ENGINE= mysql-test/t/fulltext_distinct.test: Change occurances of TYPE= to ENGINE= mysql-test/t/fulltext_left_join.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_compress.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_date_add.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_group.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_if.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_str.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_test.test: Change occurances of TYPE= to ENGINE= mysql-test/t/func_time.test: Change occurances of TYPE= to ENGINE= mysql-test/t/gis-rtree.test: Change occurances of TYPE= to ENGINE= mysql-test/t/group_by.test: Change occurances of TYPE= to ENGINE= mysql-test/t/handler.test: Change occurances of TYPE= to ENGINE= mysql-test/t/heap.test: Change occurances of TYPE= to ENGINE= mysql-test/t/heap_auto_increment.test: Change occurances of TYPE= to ENGINE= mysql-test/t/heap_btree.test: Change occurances of TYPE= to ENGINE= mysql-test/t/heap_hash.test: Change occurances of TYPE= to ENGINE= mysql-test/t/help.test: Change occurances of TYPE= to ENGINE= mysql-test/t/innodb-deadlock.test: Change occurances of TYPE= to ENGINE= mysql-test/t/innodb.test: Change occurances of TYPE= to ENGINE= mysql-test/t/innodb_cache.test: Change occurances of TYPE= to ENGINE= mysql-test/t/innodb_handler.test: Change occurances of TYPE= to ENGINE= mysql-test/t/insert_select.test: Change occurances of TYPE= to ENGINE= mysql-test/t/isam.test: Change occurances of TYPE= to ENGINE= mysql-test/t/join.test: Change occurances of TYPE= to ENGINE= mysql-test/t/join_crash.test: Change occurances of TYPE= to ENGINE= mysql-test/t/join_outer.test: Change occurances of TYPE= to ENGINE= mysql-test/t/key.test: Change occurances of TYPE= to ENGINE= mysql-test/t/lock.test: Change occurances of TYPE= to ENGINE= mysql-test/t/lock_tables_lost_commit.test: Change occurances of TYPE= to ENGINE= mysql-test/t/merge.test: Change occurances of TYPE= to ENGINE= mysql-test/t/mix_innodb_myisam_binlog.test: Change occurances of TYPE= to ENGINE= mysql-test/t/multi_update.test: Change occurances of TYPE= to ENGINE= mysql-test/t/myisam.test: Change occurances of TYPE= to ENGINE= mysql-test/t/null.test: Change occurances of TYPE= to ENGINE= mysql-test/t/null_key.test: Change occurances of TYPE= to ENGINE= mysql-test/t/order_by.test: Change occurances of TYPE= to ENGINE= mysql-test/t/outfile.test: Change occurances of TYPE= to ENGINE= mysql-test/t/query_cache.test: Change occurances of TYPE= to ENGINE= mysql-test/t/query_cache_merge.test: Change occurances of TYPE= to ENGINE= mysql-test/t/range.test: Change occurances of TYPE= to ENGINE= mysql-test/t/repair_part1.test: Change occurances of TYPE= to ENGINE= mysql-test/t/replace.test: Change occurances of TYPE= to ENGINE= mysql-test/t/rollback.test: Change occurances of TYPE= to ENGINE= mysql-test/t/rpl000006.test: Change occurances of TYPE= to ENGINE= mysql-test/t/rpl_flush_tables.test: Change occurances of TYPE= to ENGINE= mysql-test/t/rpl_insert_id.test: Change occurances of TYPE= to ENGINE= mysql-test/t/rpl_relayrotate.test: Change occurances of TYPE= to ENGINE= mysql-test/t/select.test: Change occurances of TYPE= to ENGINE= mysql-test/t/select_found.test: Change occurances of TYPE= to ENGINE= mysql-test/t/show_check.test: Change occurances of TYPE= to ENGINE= mysql-test/t/sql_mode.test: Change occurances of TYPE= to ENGINE= mysql-test/t/status.test: Change occurances of TYPE= to ENGINE= mysql-test/t/subselect.test: Change occurances of TYPE= to ENGINE= mysql-test/t/subselect2.test: Change occurances of TYPE= to ENGINE= mysql-test/t/subselect_innodb.test: Change occurances of TYPE= to ENGINE= mysql-test/t/symlink.test: Change occurances of TYPE= to ENGINE= mysql-test/t/temp_table.test: Change occurances of TYPE= to ENGINE= mysql-test/t/type_datetime.test: Change occurances of TYPE= to ENGINE= mysql-test/t/type_set.test: Change occurances of TYPE= to ENGINE= mysql-test/t/union.test: Change occurances of TYPE= to ENGINE= mysql-test/t/update.test: Change occurances of TYPE= to ENGINE= mysql-test/t/warnings.test: Change occurances of TYPE= to ENGINE= New test for deprecated syntax
2003-12-10 05:31:42 +01:00
alter table t2 engine=INNODB;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
delete from t1;
delete from t2;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
reset master;
begin;
insert into t1 values(12);
insert into t2 select * from t1;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
commit;
source include/show_binlog_events.inc;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
delete from t1;
delete from t2;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
reset master;
begin;
insert into t1 values(13);
insert into t2 select * from t1;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
rollback;
source include/show_binlog_events.inc;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
delete from t1;
delete from t2;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
reset master;
begin;
insert into t1 values(14);
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
savepoint my_savepoint;
insert into t1 values(15);
insert into t2 select * from t1;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
rollback to savepoint my_savepoint;
commit;
source include/show_binlog_events.inc;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
delete from t1;
delete from t2;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
reset master;
begin;
insert into t1 values(16);
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
savepoint my_savepoint;
insert into t1 values(17);
insert into t2 select * from t1;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
rollback to savepoint my_savepoint;
insert into t1 values(18);
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
commit;
select a from t1 order by a; # check that savepoints work :)
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
source include/show_binlog_events.inc;
2 minor edits, plus fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning" and fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog". Now we don't always write the non-trans update immediately to the binlog; if there is something in the binlog cache we write it to the binlog cache (because the non-trans update could depend on a trans table which was modified earlier in the transaction); then in case of ROLLBACK, we write the binlog cache to the binlog, wrapped with BEGIN/ROLLBACK. This guarantees that the slave does the same updates. For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated, we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog (because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO SAVEPOINT in the binlog. Apart from this rare case of updates of mixed table types in transaction, the usual way is still clear the binlog cache at ROLLBACK, or chop it at ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which is fine). Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM". client/mysqldump.c: Minor edit: one CHANGE MASTER with 2 arguments instead of 2 CHANGE MASTER with one argument each. mysql-test/r/rpl_loaddata.result: result update mysql-test/t/rpl_loaddata.test: minor edit: simplifying the test. sql/handler.cc: Fix for BUG#873. See comments in code, and the description of the changeset. sql/log.cc: * Previously, if a query updated a non-transactional table we wrote it immediately to the real binlog. This causes a bug when the update is done inside a transaction and uses the content of an updated transactional table (because this makes a wrong order of queries in the binlog). So if the binlog cache is not empty, we write the query to the binlog cache; otherwise we can write it to the binlog. * Previously, when we flushed the binlog cache to the binlog, we wrapped it with BEGIN/COMMIT. Now it's also possible to wrap it with BEGIN/ROLLBACK, to handle transactions which update both transactional and non-transactional tables. sql/log_event.cc: The slave thread can leave a transaction if COMMIT or if ROLLBACK. sql/sql_class.h: prototype sql/sql_insert.cc: Fix for BUG#1113: this was because the INSERT SELECT code did not set OPTION_STATUS_NO_TRANS_UPDATE. sql/sql_parse.cc: Don't send ER_WARNING_NOT_COMPLETE_ROLLBACK if this is the SQL slave thread (see comments).
2003-08-22 15:39:24 +02:00
# Test for BUG#5714, where a MyISAM update in the transaction used to
# release row-level locks in InnoDB
connect (con3,localhost,root,,);
connection con3;
delete from t1;
delete from t2;
--disable_warnings
alter table t2 type=MyISAM;
--enable_warnings
insert into t1 values (1);
begin;
select * from t1 for update;
connection con2;
select (@before:=unix_timestamp())*0; # always give repeatable output
begin;
send select * from t1 for update;
connection con3;
insert into t2 values (20);
connection con2;
--error 1205
reap;
select (@after:=unix_timestamp())*0; # always give repeatable output
# verify that innodb_lock_wait_timeout was exceeded. When there was
# the bug, the reap would return immediately after the insert into t2.
select (@after-@before) >= 2;
drop table t1,t2;
commit;
# test for BUG#7947 - DO RELEASE_LOCK() not written to binlog on rollback in the middle
# of a transaction
connection con2;
begin;
create temporary table ti (a int) engine=innodb;
rollback;
insert into ti values(1);
set autocommit=0;
create temporary table t1 (a int) engine=myisam;
commit;
insert t1 values (1);
rollback;
create table t0 (n int);
insert t0 select * from t1;
set autocommit=1;
insert into t0 select GET_LOCK("lock1",null);
set autocommit=0;
create table t2 (n int) engine=innodb;
insert into t2 values (3);
disconnect con2;
connection con3;
select get_lock("lock1",60);
source include/show_binlog_events.inc;
do release_lock("lock1");
drop table t0,t2;
# Test for BUG#16559 (ROLLBACK should always have a zero error code in
# binlog). Has to be here and not earlier, as the SELECTs influence
# XIDs differently between normal and ps-protocol (and SHOW BINLOG
# EVENTS above read XIDs).
connect (con4,localhost,root,,);
connection con3;
reset master;
create table t1 (a int) engine=innodb;
create table t2 (a int) engine=myisam;
select get_lock("a",10);
begin;
insert into t1 values(8);
insert into t2 select * from t1;
disconnect con3;
connection con4;
select get_lock("a",10); # wait for rollback to finish
# we check that the error code of the "ROLLBACK" event is 0 and not
# ER_SERVER_SHUTDOWN (i.e. disconnection just rolls back transaction
# and does not make slave to stop)
--exec $MYSQL_BINLOG --start-position=547 $MYSQLTEST_VARDIR/log/master-bin.000001 > $MYSQLTEST_VARDIR/tmp/mix_innodb_myisam_binlog.output
--replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR
eval select
(@a:=load_file("$MYSQLTEST_VARDIR/tmp/mix_innodb_myisam_binlog.output"))
is not null;
--replace_result $MYSQL_TEST_DIR MYSQL_TEST_DIR
eval select
@a like "%#%error_code=0%ROLLBACK\\n/*!*/;%ROLLBACK /* added by mysqlbinlog */;%" OR
@a like "%#%error_code=0%ROLLBACK\\r\\n/*!*/;%ROLLBACK /* added by mysqlbinlog */;%",
@a not like "%#%error_code=%error_code=%";
drop table t1, t2;
(pushing for Andrei) Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack Once had been set the flag might later got reset inside of a stored routine execution stack. The reason was in that there was no check if a new statement started at time of resetting. The artifact affects most of binlogable DML queries. Notice, that multi-update is wrapped up within bug@27716 fix, multi-delete bug@29136. Fixed with saving parent's statement flag of whether the statement modified non-transactional table, and unioning (merging) the value with that was gained in mysql_execute_command. Resettling thd->no_trans_update members into thd->transaction.`member`; Asserting code; Effectively the following properties are held. 1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table reflects the fact if such a table got modified by the substatement. That also respects THD::really_abort_on_warnin() requirements. 2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as the union of the values of all invoked sub-statements. That fixes this bug#27417; Computing of thd->transaction.all.modified_non_trans_table is refined to base to the stmt's value for all the case including insert .. select statement which before the patch had an extra issue bug@28960. Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in to temp_table select. The supplied test verifies limitely, mostly asserts. The ultimate testing is defered for bug@13270, bug@23333. mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/t/mix_innodb_myisam_binlog.test: regression test incl the related bug#28960. sql/ha_ndbcluster.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/handler.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/handler.h: new member added sql/log.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/set_var.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sp_head.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} and saving and merging stmt's flag at the end of a substatement. sql/sql_class.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_class.h: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_delete.cc: correcting basic delete incl truncate branch and multi-delete queries to set stmt.modified_non_trans_table; optimization to set the flag at the end of per-row loop; multi-delete still has an extra issue similar to bug#27716 of multi-update - to be address with bug_29136 fix. sql/sql_insert.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_load.cc: eliminating a separate issue where the stmt flag was saved and re-stored after write_record that actually could change it and the change would be lost but should remain permanent; thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_parse.cc: initialization to transaction.stmt.modified_non_trans_table at the common part of all types of statements processing - mysql_execute_command(). sql/sql_table.cc: moving the reset up to the mysql_execute_command() caller sql/sql_update.cc: correcting update query case (multi-update part of the issues covered by other bug#27716 fix) thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt}
2007-07-30 17:27:36 +02:00
#
# Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack
# bug #28960 non-trans temp table changes with insert .. select
# not binlogged after rollback
#
# testing appearence of insert into temp_table in binlog.
# There are two branches of execution that require different setup.
## send_eof() branch
# prepare
create temporary table tt (a int unique);
create table ti (a int) engine=innodb;
reset master;
show master status;
# action
begin;
insert into ti values (1);
insert into ti values (2) ;
insert into tt select * from ti;
rollback;
# check
select count(*) from tt /* 2 */;
show master status;
--replace_column 2 # 5 #
show binlog events from 98;
select count(*) from ti /* zero */;
insert into ti select * from tt;
select * from ti /* that is what slave would miss - a bug */;
## send_error() branch
delete from ti;
delete from tt where a=1;
reset master;
show master status;
# action
begin;
insert into ti values (1);
insert into ti values (2) /* to make the dup error in the following */;
--error ER_DUP_ENTRY
insert into tt select * from ti /* one affected and error */;
rollback;
# check
show master status;
--replace_column 2 # 5 #
show binlog events from 98;
select count(*) from ti /* zero */;
insert into ti select * from tt;
select * from tt /* that is what otherwise slave missed - the bug */;
drop table ti;
#
# Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack
#
# Testing asserts: if there is a side effect of modifying non-transactional
# table thd->no_trans_update.stmt must be TRUE;
# the assert is active with debug build
#
--disable_warnings
drop function if exists bug27417;
drop table if exists t1,t2;
--enable_warnings
# side effect table
CREATE TABLE t1 (a int NOT NULL auto_increment primary key) ENGINE=MyISAM;
# target tables
CREATE TABLE t2 (a int NOT NULL auto_increment, PRIMARY KEY (a));
delimiter |;
Bug #29136 erred multi-delete on trans table does not rollback the statement similar to bug_27716, but it was stressed on in the synopsis on that there is another side of the artifact affecting behaviour in transaction. Fixed with deploying multi_delete::send_error() - otherwise never called - and refining its logic to perform binlogging job if needed. The changeset includes the following side effects: - added tests to check bug_23333's scenarios on the mixture of tables for multi_update; - fixes bug@30763 with two-liner patch and a test coinciding to one added for bug_23333. mysql-test/r/innodb.result: results changed mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/r/multi_update.result: results changed mysql-test/t/innodb.test: trans table specific test added mysql-test/t/mix_innodb_myisam_binlog.test: multi-update and multi-delete of mixure of ta and not-ta tables tests added (relates to bug_23333). mysql-test/t/multi_update.test: testing another branch of mult-delete: send_eof() (binloggin there), send_error (early return) sql/sql_class.h: a new flag to designate the fact the statement's error has been handled. The flag is checked by ::send_error() methods (multi_update and _delete classes) sql/sql_delete.cc: expanding multi_delete::send_error to 1. early return if error_handled == t 2. binlogging locally if there was a non-trans table modified side effect sql/sql_parse.cc: adding multi_update::send_error which can perform binlogging and rollback job in needed sql/sql_update.cc: issues relating to 1. bug_27716 with zeroing of `updated' to serve as the flag of early return from send_error(). The flag is changed to be a new member error_handled; also moved outside binlogging branch. The reason for this change is that bug_23333 fixes were pushed after the bug_27716's and they left this flaw (also no test coverage). 2. bug_30763 with assertion on trans_safe. I decide to make 2 liner fix for that bug here instead of to remove those two assertions. This new bug test case is the same as for multi-update on the mixure of tables. The rational for this fix: presumption for mutli_update::trans_safe to be set to zero at multi_update::multi_update or multi_update::initialize_tables() is incorrect. trans_safe := false should happen only when a non-transactional table gets modified. Therefore, at initialization the member must be be set to true.
2007-10-13 14:49:42 +02:00
create function bug27417(n int)
(pushing for Andrei) Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack Once had been set the flag might later got reset inside of a stored routine execution stack. The reason was in that there was no check if a new statement started at time of resetting. The artifact affects most of binlogable DML queries. Notice, that multi-update is wrapped up within bug@27716 fix, multi-delete bug@29136. Fixed with saving parent's statement flag of whether the statement modified non-transactional table, and unioning (merging) the value with that was gained in mysql_execute_command. Resettling thd->no_trans_update members into thd->transaction.`member`; Asserting code; Effectively the following properties are held. 1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table reflects the fact if such a table got modified by the substatement. That also respects THD::really_abort_on_warnin() requirements. 2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as the union of the values of all invoked sub-statements. That fixes this bug#27417; Computing of thd->transaction.all.modified_non_trans_table is refined to base to the stmt's value for all the case including insert .. select statement which before the patch had an extra issue bug@28960. Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in to temp_table select. The supplied test verifies limitely, mostly asserts. The ultimate testing is defered for bug@13270, bug@23333. mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/t/mix_innodb_myisam_binlog.test: regression test incl the related bug#28960. sql/ha_ndbcluster.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/handler.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/handler.h: new member added sql/log.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/set_var.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sp_head.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} and saving and merging stmt's flag at the end of a substatement. sql/sql_class.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_class.h: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_delete.cc: correcting basic delete incl truncate branch and multi-delete queries to set stmt.modified_non_trans_table; optimization to set the flag at the end of per-row loop; multi-delete still has an extra issue similar to bug#27716 of multi-update - to be address with bug_29136 fix. sql/sql_insert.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_load.cc: eliminating a separate issue where the stmt flag was saved and re-stored after write_record that actually could change it and the change would be lost but should remain permanent; thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_parse.cc: initialization to transaction.stmt.modified_non_trans_table at the common part of all types of statements processing - mysql_execute_command(). sql/sql_table.cc: moving the reset up to the mysql_execute_command() caller sql/sql_update.cc: correcting update query case (multi-update part of the issues covered by other bug#27716 fix) thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt}
2007-07-30 17:27:36 +02:00
RETURNS int(11)
begin
insert into t1 values (null);
return n;
end|
delimiter ;|
reset master;
# execute
insert into t2 values (bug27417(1));
insert into t2 select bug27417(2);
reset master;
--error ER_DUP_ENTRY
insert into t2 values (bug27417(2));
show master status; /* only (!) with fixes for #23333 will show there is the query */;
select count(*) from t1 /* must be 3 */;
reset master;
select count(*) from t2;
delete from t2 where a=bug27417(3);
select count(*) from t2 /* nothing got deleted */;
show master status; /* the query must be in regardless of #23333 */;
select count(*) from t1 /* must be 5 */;
--enable_info
delete t2 from t2 where t2.a=bug27417(100) /* must not affect t2 */;
--disable_info
select count(*) from t1 /* must be 7 */;
# function bug27417 remains for the following testing of bug#23333
(pushing for Andrei) Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack Once had been set the flag might later got reset inside of a stored routine execution stack. The reason was in that there was no check if a new statement started at time of resetting. The artifact affects most of binlogable DML queries. Notice, that multi-update is wrapped up within bug@27716 fix, multi-delete bug@29136. Fixed with saving parent's statement flag of whether the statement modified non-transactional table, and unioning (merging) the value with that was gained in mysql_execute_command. Resettling thd->no_trans_update members into thd->transaction.`member`; Asserting code; Effectively the following properties are held. 1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table reflects the fact if such a table got modified by the substatement. That also respects THD::really_abort_on_warnin() requirements. 2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as the union of the values of all invoked sub-statements. That fixes this bug#27417; Computing of thd->transaction.all.modified_non_trans_table is refined to base to the stmt's value for all the case including insert .. select statement which before the patch had an extra issue bug@28960. Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in to temp_table select. The supplied test verifies limitely, mostly asserts. The ultimate testing is defered for bug@13270, bug@23333. mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/t/mix_innodb_myisam_binlog.test: regression test incl the related bug#28960. sql/ha_ndbcluster.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/handler.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/handler.h: new member added sql/log.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/set_var.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sp_head.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} and saving and merging stmt's flag at the end of a substatement. sql/sql_class.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_class.h: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_delete.cc: correcting basic delete incl truncate branch and multi-delete queries to set stmt.modified_non_trans_table; optimization to set the flag at the end of per-row loop; multi-delete still has an extra issue similar to bug#27716 of multi-update - to be address with bug_29136 fix. sql/sql_insert.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_load.cc: eliminating a separate issue where the stmt flag was saved and re-stored after write_record that actually could change it and the change would be lost but should remain permanent; thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_parse.cc: initialization to transaction.stmt.modified_non_trans_table at the common part of all types of statements processing - mysql_execute_command(). sql/sql_table.cc: moving the reset up to the mysql_execute_command() caller sql/sql_update.cc: correcting update query case (multi-update part of the issues covered by other bug#27716 fix) thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt}
2007-07-30 17:27:36 +02:00
drop table t1,t2;
#
# Bug#23333 using the patch (and the test) for bug#27471
Bug #29136 erred multi-delete on trans table does not rollback the statement similar to bug_27716, but it was stressed on in the synopsis on that there is another side of the artifact affecting behaviour in transaction. Fixed with deploying multi_delete::send_error() - otherwise never called - and refining its logic to perform binlogging job if needed. The changeset includes the following side effects: - added tests to check bug_23333's scenarios on the mixture of tables for multi_update; - fixes bug@30763 with two-liner patch and a test coinciding to one added for bug_23333. mysql-test/r/innodb.result: results changed mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/r/multi_update.result: results changed mysql-test/t/innodb.test: trans table specific test added mysql-test/t/mix_innodb_myisam_binlog.test: multi-update and multi-delete of mixure of ta and not-ta tables tests added (relates to bug_23333). mysql-test/t/multi_update.test: testing another branch of mult-delete: send_eof() (binloggin there), send_error (early return) sql/sql_class.h: a new flag to designate the fact the statement's error has been handled. The flag is checked by ::send_error() methods (multi_update and _delete classes) sql/sql_delete.cc: expanding multi_delete::send_error to 1. early return if error_handled == t 2. binlogging locally if there was a non-trans table modified side effect sql/sql_parse.cc: adding multi_update::send_error which can perform binlogging and rollback job in needed sql/sql_update.cc: issues relating to 1. bug_27716 with zeroing of `updated' to serve as the flag of early return from send_error(). The flag is changed to be a new member error_handled; also moved outside binlogging branch. The reason for this change is that bug_23333 fixes were pushed after the bug_27716's and they left this flaw (also no test coverage). 2. bug_30763 with assertion on trans_safe. I decide to make 2 liner fix for that bug here instead of to remove those two assertions. This new bug test case is the same as for multi-update on the mixure of tables. The rational for this fix: presumption for mutli_update::trans_safe to be set to zero at multi_update::multi_update or multi_update::initialize_tables() is incorrect. trans_safe := false should happen only when a non-transactional table gets modified. Therefore, at initialization the member must be be set to true.
2007-10-13 14:49:42 +02:00
#
# throughout the bug tests
# t1 - non-trans side effects gatherer;
# t2 - transactional table;
#
Bug #29136 erred multi-delete on trans table does not rollback the statement similar to bug_27716, but it was stressed on in the synopsis on that there is another side of the artifact affecting behaviour in transaction. Fixed with deploying multi_delete::send_error() - otherwise never called - and refining its logic to perform binlogging job if needed. The changeset includes the following side effects: - added tests to check bug_23333's scenarios on the mixture of tables for multi_update; - fixes bug@30763 with two-liner patch and a test coinciding to one added for bug_23333. mysql-test/r/innodb.result: results changed mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/r/multi_update.result: results changed mysql-test/t/innodb.test: trans table specific test added mysql-test/t/mix_innodb_myisam_binlog.test: multi-update and multi-delete of mixure of ta and not-ta tables tests added (relates to bug_23333). mysql-test/t/multi_update.test: testing another branch of mult-delete: send_eof() (binloggin there), send_error (early return) sql/sql_class.h: a new flag to designate the fact the statement's error has been handled. The flag is checked by ::send_error() methods (multi_update and _delete classes) sql/sql_delete.cc: expanding multi_delete::send_error to 1. early return if error_handled == t 2. binlogging locally if there was a non-trans table modified side effect sql/sql_parse.cc: adding multi_update::send_error which can perform binlogging and rollback job in needed sql/sql_update.cc: issues relating to 1. bug_27716 with zeroing of `updated' to serve as the flag of early return from send_error(). The flag is changed to be a new member error_handled; also moved outside binlogging branch. The reason for this change is that bug_23333 fixes were pushed after the bug_27716's and they left this flaw (also no test coverage). 2. bug_30763 with assertion on trans_safe. I decide to make 2 liner fix for that bug here instead of to remove those two assertions. This new bug test case is the same as for multi-update on the mixure of tables. The rational for this fix: presumption for mutli_update::trans_safe to be set to zero at multi_update::multi_update or multi_update::initialize_tables() is incorrect. trans_safe := false should happen only when a non-transactional table gets modified. Therefore, at initialization the member must be be set to true.
2007-10-13 14:49:42 +02:00
CREATE TABLE t1 (a int NOT NULL auto_increment primary key) ENGINE=MyISAM;
CREATE TABLE t2 (a int, PRIMARY KEY (a)) ENGINE=InnoDB;
Bug #29136 erred multi-delete on trans table does not rollback the statement similar to bug_27716, but it was stressed on in the synopsis on that there is another side of the artifact affecting behaviour in transaction. Fixed with deploying multi_delete::send_error() - otherwise never called - and refining its logic to perform binlogging job if needed. The changeset includes the following side effects: - added tests to check bug_23333's scenarios on the mixture of tables for multi_update; - fixes bug@30763 with two-liner patch and a test coinciding to one added for bug_23333. mysql-test/r/innodb.result: results changed mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/r/multi_update.result: results changed mysql-test/t/innodb.test: trans table specific test added mysql-test/t/mix_innodb_myisam_binlog.test: multi-update and multi-delete of mixure of ta and not-ta tables tests added (relates to bug_23333). mysql-test/t/multi_update.test: testing another branch of mult-delete: send_eof() (binloggin there), send_error (early return) sql/sql_class.h: a new flag to designate the fact the statement's error has been handled. The flag is checked by ::send_error() methods (multi_update and _delete classes) sql/sql_delete.cc: expanding multi_delete::send_error to 1. early return if error_handled == t 2. binlogging locally if there was a non-trans table modified side effect sql/sql_parse.cc: adding multi_update::send_error which can perform binlogging and rollback job in needed sql/sql_update.cc: issues relating to 1. bug_27716 with zeroing of `updated' to serve as the flag of early return from send_error(). The flag is changed to be a new member error_handled; also moved outside binlogging branch. The reason for this change is that bug_23333 fixes were pushed after the bug_27716's and they left this flaw (also no test coverage). 2. bug_30763 with assertion on trans_safe. I decide to make 2 liner fix for that bug here instead of to remove those two assertions. This new bug test case is the same as for multi-update on the mixure of tables. The rational for this fix: presumption for mutli_update::trans_safe to be set to zero at multi_update::multi_update or multi_update::initialize_tables() is incorrect. trans_safe := false should happen only when a non-transactional table gets modified. Therefore, at initialization the member must be be set to true.
2007-10-13 14:49:42 +02:00
CREATE TABLE t3 (a int, PRIMARY KEY (a), b int unique) ENGINE=MyISAM;
CREATE TABLE t4 (a int, PRIMARY KEY (a), b int unique) ENGINE=Innodb;
CREATE TABLE t5 (a int, PRIMARY KEY (a)) ENGINE=InnoDB;
#
# INSERT
#
# prepare
insert into t2 values (1);
reset master;
# execute
--error ER_DUP_ENTRY
insert into t2 values (bug27417(1));
# check
show master status /* the offset must denote there is the query */;
select count(*) from t1 /* must be 1 */;
#
# INSERT SELECT
#
# prepare
delete from t1;
delete from t2;
insert into t2 values (2);
reset master;
# execute
--error ER_DUP_ENTRY
insert into t2 select bug27417(1) union select bug27417(2);
# check
show master status /* the offset must denote there is the query */;
select count(*) from t1 /* must be 2 */;
#
Bug #29136 erred multi-delete on trans table does not rollback the statement similar to bug_27716, but it was stressed on in the synopsis on that there is another side of the artifact affecting behaviour in transaction. Fixed with deploying multi_delete::send_error() - otherwise never called - and refining its logic to perform binlogging job if needed. The changeset includes the following side effects: - added tests to check bug_23333's scenarios on the mixture of tables for multi_update; - fixes bug@30763 with two-liner patch and a test coinciding to one added for bug_23333. mysql-test/r/innodb.result: results changed mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/r/multi_update.result: results changed mysql-test/t/innodb.test: trans table specific test added mysql-test/t/mix_innodb_myisam_binlog.test: multi-update and multi-delete of mixure of ta and not-ta tables tests added (relates to bug_23333). mysql-test/t/multi_update.test: testing another branch of mult-delete: send_eof() (binloggin there), send_error (early return) sql/sql_class.h: a new flag to designate the fact the statement's error has been handled. The flag is checked by ::send_error() methods (multi_update and _delete classes) sql/sql_delete.cc: expanding multi_delete::send_error to 1. early return if error_handled == t 2. binlogging locally if there was a non-trans table modified side effect sql/sql_parse.cc: adding multi_update::send_error which can perform binlogging and rollback job in needed sql/sql_update.cc: issues relating to 1. bug_27716 with zeroing of `updated' to serve as the flag of early return from send_error(). The flag is changed to be a new member error_handled; also moved outside binlogging branch. The reason for this change is that bug_23333 fixes were pushed after the bug_27716's and they left this flaw (also no test coverage). 2. bug_30763 with assertion on trans_safe. I decide to make 2 liner fix for that bug here instead of to remove those two assertions. This new bug test case is the same as for multi-update on the mixure of tables. The rational for this fix: presumption for mutli_update::trans_safe to be set to zero at multi_update::multi_update or multi_update::initialize_tables() is incorrect. trans_safe := false should happen only when a non-transactional table gets modified. Therefore, at initialization the member must be be set to true.
2007-10-13 14:49:42 +02:00
# UPDATE inc multi-update
#
# prepare
delete from t1;
insert into t3 values (1,1),(2,3),(3,4);
reset master;
# execute
--error ER_DUP_ENTRY
update t3 set b=b+bug27417(1);
# check
show master status /* the offset must denote there is the query */;
select count(*) from t1 /* must be 2 */;
Bug #29136 erred multi-delete on trans table does not rollback the statement similar to bug_27716, but it was stressed on in the synopsis on that there is another side of the artifact affecting behaviour in transaction. Fixed with deploying multi_delete::send_error() - otherwise never called - and refining its logic to perform binlogging job if needed. The changeset includes the following side effects: - added tests to check bug_23333's scenarios on the mixture of tables for multi_update; - fixes bug@30763 with two-liner patch and a test coinciding to one added for bug_23333. mysql-test/r/innodb.result: results changed mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/r/multi_update.result: results changed mysql-test/t/innodb.test: trans table specific test added mysql-test/t/mix_innodb_myisam_binlog.test: multi-update and multi-delete of mixure of ta and not-ta tables tests added (relates to bug_23333). mysql-test/t/multi_update.test: testing another branch of mult-delete: send_eof() (binloggin there), send_error (early return) sql/sql_class.h: a new flag to designate the fact the statement's error has been handled. The flag is checked by ::send_error() methods (multi_update and _delete classes) sql/sql_delete.cc: expanding multi_delete::send_error to 1. early return if error_handled == t 2. binlogging locally if there was a non-trans table modified side effect sql/sql_parse.cc: adding multi_update::send_error which can perform binlogging and rollback job in needed sql/sql_update.cc: issues relating to 1. bug_27716 with zeroing of `updated' to serve as the flag of early return from send_error(). The flag is changed to be a new member error_handled; also moved outside binlogging branch. The reason for this change is that bug_23333 fixes were pushed after the bug_27716's and they left this flaw (also no test coverage). 2. bug_30763 with assertion on trans_safe. I decide to make 2 liner fix for that bug here instead of to remove those two assertions. This new bug test case is the same as for multi-update on the mixure of tables. The rational for this fix: presumption for mutli_update::trans_safe to be set to zero at multi_update::multi_update or multi_update::initialize_tables() is incorrect. trans_safe := false should happen only when a non-transactional table gets modified. Therefore, at initialization the member must be be set to true.
2007-10-13 14:49:42 +02:00
## multi_update::send_eof() branch
# prepare
delete from t3;
delete from t4;
insert into t3 values (1,1);
insert into t4 values (1,1),(2,2);
reset master;
# execute
--error ER_DUP_ENTRY
UPDATE t4,t3 SET t4.a=t3.a + bug27417(1) /* top level non-ta table */;
# check
show master status /* the offset must denote there is the query */;
select count(*) from t1 /* must be 4 */;
## send_error() branch of multi_update
# prepare
delete from t1;
delete from t3;
delete from t4;
insert into t3 values (1,1),(2,2);
insert into t4 values (1,1),(2,2);
reset master;
# execute
--error ER_DUP_ENTRY
UPDATE t3,t4 SET t3.a=t4.a + bug27417(1);
# check
select count(*) from t1 /* must be 1 */;
# cleanup
drop table t4;
#
Bug #29136 erred multi-delete on trans table does not rollback the statement similar to bug_27716, but it was stressed on in the synopsis on that there is another side of the artifact affecting behaviour in transaction. Fixed with deploying multi_delete::send_error() - otherwise never called - and refining its logic to perform binlogging job if needed. The changeset includes the following side effects: - added tests to check bug_23333's scenarios on the mixture of tables for multi_update; - fixes bug@30763 with two-liner patch and a test coinciding to one added for bug_23333. mysql-test/r/innodb.result: results changed mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/r/multi_update.result: results changed mysql-test/t/innodb.test: trans table specific test added mysql-test/t/mix_innodb_myisam_binlog.test: multi-update and multi-delete of mixure of ta and not-ta tables tests added (relates to bug_23333). mysql-test/t/multi_update.test: testing another branch of mult-delete: send_eof() (binloggin there), send_error (early return) sql/sql_class.h: a new flag to designate the fact the statement's error has been handled. The flag is checked by ::send_error() methods (multi_update and _delete classes) sql/sql_delete.cc: expanding multi_delete::send_error to 1. early return if error_handled == t 2. binlogging locally if there was a non-trans table modified side effect sql/sql_parse.cc: adding multi_update::send_error which can perform binlogging and rollback job in needed sql/sql_update.cc: issues relating to 1. bug_27716 with zeroing of `updated' to serve as the flag of early return from send_error(). The flag is changed to be a new member error_handled; also moved outside binlogging branch. The reason for this change is that bug_23333 fixes were pushed after the bug_27716's and they left this flaw (also no test coverage). 2. bug_30763 with assertion on trans_safe. I decide to make 2 liner fix for that bug here instead of to remove those two assertions. This new bug test case is the same as for multi-update on the mixure of tables. The rational for this fix: presumption for mutli_update::trans_safe to be set to zero at multi_update::multi_update or multi_update::initialize_tables() is incorrect. trans_safe := false should happen only when a non-transactional table gets modified. Therefore, at initialization the member must be be set to true.
2007-10-13 14:49:42 +02:00
# DELETE incl multi-delete
#
# prepare
delete from t1;
delete from t2;
delete from t3;
insert into t2 values (1);
insert into t3 values (1,1);
create trigger trg_del before delete on t2 for each row
insert into t3 values (bug27417(1), 2);
reset master;
# execute
--error ER_DUP_ENTRY
delete from t2;
# check
show master status /* the offset must denote there is the query */;
select count(*) from t1 /* must be 1 */;
Bug #29136 erred multi-delete on trans table does not rollback the statement similar to bug_27716, but it was stressed on in the synopsis on that there is another side of the artifact affecting behaviour in transaction. Fixed with deploying multi_delete::send_error() - otherwise never called - and refining its logic to perform binlogging job if needed. The changeset includes the following side effects: - added tests to check bug_23333's scenarios on the mixture of tables for multi_update; - fixes bug@30763 with two-liner patch and a test coinciding to one added for bug_23333. mysql-test/r/innodb.result: results changed mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/r/multi_update.result: results changed mysql-test/t/innodb.test: trans table specific test added mysql-test/t/mix_innodb_myisam_binlog.test: multi-update and multi-delete of mixure of ta and not-ta tables tests added (relates to bug_23333). mysql-test/t/multi_update.test: testing another branch of mult-delete: send_eof() (binloggin there), send_error (early return) sql/sql_class.h: a new flag to designate the fact the statement's error has been handled. The flag is checked by ::send_error() methods (multi_update and _delete classes) sql/sql_delete.cc: expanding multi_delete::send_error to 1. early return if error_handled == t 2. binlogging locally if there was a non-trans table modified side effect sql/sql_parse.cc: adding multi_update::send_error which can perform binlogging and rollback job in needed sql/sql_update.cc: issues relating to 1. bug_27716 with zeroing of `updated' to serve as the flag of early return from send_error(). The flag is changed to be a new member error_handled; also moved outside binlogging branch. The reason for this change is that bug_23333 fixes were pushed after the bug_27716's and they left this flaw (also no test coverage). 2. bug_30763 with assertion on trans_safe. I decide to make 2 liner fix for that bug here instead of to remove those two assertions. This new bug test case is the same as for multi-update on the mixure of tables. The rational for this fix: presumption for mutli_update::trans_safe to be set to zero at multi_update::multi_update or multi_update::initialize_tables() is incorrect. trans_safe := false should happen only when a non-transactional table gets modified. Therefore, at initialization the member must be be set to true.
2007-10-13 14:49:42 +02:00
# cleanup
drop trigger trg_del;
# prepare
delete from t1;
delete from t2;
delete from t5;
create trigger trg_del_t2 after delete on t2 for each row
insert into t1 values (1);
insert into t2 values (2),(3);
insert into t5 values (1),(2);
reset master;
# execute
--error ER_DUP_ENTRY
delete t2.* from t2,t5 where t2.a=t5.a + 1;
# check
show master status /* the offset must denote there is the query */;
select count(*) from t1 /* must be 1 */;
#
# LOAD DATA
#
# prepare
delete from t1;
create table t4 (a int default 0, b int primary key) engine=innodb;
insert into t4 values (0, 17);
reset master;
# execute
--error ER_DUP_ENTRY
load data infile '../std_data_ln/rpl_loaddata.dat' into table t4 (a, @b) set b= @b + bug27417(2);
# check
select * from t4;
select count(*) from t1 /* must be 2 */;
show master status /* the offset must denote there is the query */;
#
# bug#23333 cleanup
#
Bug #29136 erred multi-delete on trans table does not rollback the statement similar to bug_27716, but it was stressed on in the synopsis on that there is another side of the artifact affecting behaviour in transaction. Fixed with deploying multi_delete::send_error() - otherwise never called - and refining its logic to perform binlogging job if needed. The changeset includes the following side effects: - added tests to check bug_23333's scenarios on the mixture of tables for multi_update; - fixes bug@30763 with two-liner patch and a test coinciding to one added for bug_23333. mysql-test/r/innodb.result: results changed mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/r/multi_update.result: results changed mysql-test/t/innodb.test: trans table specific test added mysql-test/t/mix_innodb_myisam_binlog.test: multi-update and multi-delete of mixure of ta and not-ta tables tests added (relates to bug_23333). mysql-test/t/multi_update.test: testing another branch of mult-delete: send_eof() (binloggin there), send_error (early return) sql/sql_class.h: a new flag to designate the fact the statement's error has been handled. The flag is checked by ::send_error() methods (multi_update and _delete classes) sql/sql_delete.cc: expanding multi_delete::send_error to 1. early return if error_handled == t 2. binlogging locally if there was a non-trans table modified side effect sql/sql_parse.cc: adding multi_update::send_error which can perform binlogging and rollback job in needed sql/sql_update.cc: issues relating to 1. bug_27716 with zeroing of `updated' to serve as the flag of early return from send_error(). The flag is changed to be a new member error_handled; also moved outside binlogging branch. The reason for this change is that bug_23333 fixes were pushed after the bug_27716's and they left this flaw (also no test coverage). 2. bug_30763 with assertion on trans_safe. I decide to make 2 liner fix for that bug here instead of to remove those two assertions. This new bug test case is the same as for multi-update on the mixure of tables. The rational for this fix: presumption for mutli_update::trans_safe to be set to zero at multi_update::multi_update or multi_update::initialize_tables() is incorrect. trans_safe := false should happen only when a non-transactional table gets modified. Therefore, at initialization the member must be be set to true.
2007-10-13 14:49:42 +02:00
drop trigger trg_del_t2;
drop table t1,t2,t3,t4,t5;
drop function bug27417;
(pushing for Andrei) Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack Once had been set the flag might later got reset inside of a stored routine execution stack. The reason was in that there was no check if a new statement started at time of resetting. The artifact affects most of binlogable DML queries. Notice, that multi-update is wrapped up within bug@27716 fix, multi-delete bug@29136. Fixed with saving parent's statement flag of whether the statement modified non-transactional table, and unioning (merging) the value with that was gained in mysql_execute_command. Resettling thd->no_trans_update members into thd->transaction.`member`; Asserting code; Effectively the following properties are held. 1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table reflects the fact if such a table got modified by the substatement. That also respects THD::really_abort_on_warnin() requirements. 2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as the union of the values of all invoked sub-statements. That fixes this bug#27417; Computing of thd->transaction.all.modified_non_trans_table is refined to base to the stmt's value for all the case including insert .. select statement which before the patch had an extra issue bug@28960. Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in to temp_table select. The supplied test verifies limitely, mostly asserts. The ultimate testing is defered for bug@13270, bug@23333. mysql-test/r/mix_innodb_myisam_binlog.result: results changed mysql-test/t/mix_innodb_myisam_binlog.test: regression test incl the related bug#28960. sql/ha_ndbcluster.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/handler.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/handler.h: new member added sql/log.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/set_var.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sp_head.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} and saving and merging stmt's flag at the end of a substatement. sql/sql_class.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_class.h: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_delete.cc: correcting basic delete incl truncate branch and multi-delete queries to set stmt.modified_non_trans_table; optimization to set the flag at the end of per-row loop; multi-delete still has an extra issue similar to bug#27716 of multi-update - to be address with bug_29136 fix. sql/sql_insert.cc: thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_load.cc: eliminating a separate issue where the stmt flag was saved and re-stored after write_record that actually could change it and the change would be lost but should remain permanent; thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt} sql/sql_parse.cc: initialization to transaction.stmt.modified_non_trans_table at the common part of all types of statements processing - mysql_execute_command(). sql/sql_table.cc: moving the reset up to the mysql_execute_command() caller sql/sql_update.cc: correcting update query case (multi-update part of the issues covered by other bug#27716 fix) thd->transaction.{all,stmt}.modified_non_trans_table instead of thd->no_trans_update.{all,stmt}
2007-07-30 17:27:36 +02:00
--echo end of tests