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
|
2003-09-09 19:06:50 +02:00
|
|
|
# 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
|
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
|
|
|
|
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
|
|
|
|
|
2003-09-09 19:06:50 +02:00
|
|
|
--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;
|
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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
|
|
|
|
2007-06-08 11:30:03 +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
|
|
|
|
2003-09-09 19:06:50 +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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
|
|
|
|
2007-06-08 11:30:03 +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
|
|
|
|
2003-09-09 19:06:50 +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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
|
|
|
|
2007-06-08 11:30:03 +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
|
|
|
|
2003-09-09 19:06:50 +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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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
|
|
|
|
2007-06-08 11:30:03 +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?
|
2003-09-09 19:06:50 +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;
|
|
|
|
|
|
|
|
select get_lock("a",10);
|
|
|
|
begin;
|
2003-09-09 19:06:50 +02:00
|
|
|
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);
|
2007-06-08 11:30:03 +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
|
|
|
|
2003-09-09 19:06:50 +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;
|
|
|
|
|
2003-09-09 19:06:50 +02:00
|
|
|
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
|
|
|
|
2007-06-08 11:30:03 +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
|
|
|
|
2003-09-09 19:06:50 +02:00
|
|
|
# Check that when the query updat1ng the MyISAM table is the first in the
|
2003-12-20 00:38:30 +01:00
|
|
|
# transaction, we log it immediately.
|
2003-09-09 19:06:50 +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;
|
|
|
|
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
2003-09-09 19:06:50 +02:00
|
|
|
insert into t2 select * from t1;
|
2007-06-08 11:30:03 +02:00
|
|
|
source include/show_binlog_events.inc;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
|
|
|
|
2007-06-08 11:30:03 +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
|
|
|
|
2003-09-09 19:06:50 +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
|
|
|
|
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
|
|
|
|
2003-09-09 19:06:50 +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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
|
|
|
|
2007-06-08 11:30:03 +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
|
|
|
|
2003-09-09 19:06:50 +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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
|
|
|
|
2007-06-08 11:30:03 +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
|
|
|
|
2003-09-09 19:06:50 +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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
|
|
|
|
2007-06-08 11:30:03 +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
|
|
|
|
2003-09-09 19:06:50 +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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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;
|
2003-09-09 19:06:50 +02:00
|
|
|
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
|
|
|
|
2007-06-08 11:30:03 +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
|
|
|
|
2004-11-04 19:19:23 +01: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;
|
|
|
|
|
2003-09-09 19:06:50 +02:00
|
|
|
drop table t1,t2;
|
2005-11-15 21:38:06 +01:00
|
|
|
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;
|
2005-11-17 05:17:38 +01:00
|
|
|
create temporary table t1 (a int) engine=myisam;
|
|
|
|
commit;
|
|
|
|
insert t1 values (1);
|
|
|
|
rollback;
|
2005-11-15 21:38:06 +01:00
|
|
|
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;
|
2005-11-17 05:17:38 +01:00
|
|
|
select get_lock("lock1",60);
|
2007-06-08 11:30:03 +02:00
|
|
|
source include/show_binlog_events.inc;
|
2005-11-15 21:38:06 +01:00
|
|
|
do release_lock("lock1");
|
|
|
|
drop table t0,t2;
|
|
|
|
|
2005-07-28 02:22:47 +02:00
|
|
|
# End of 4.1 tests
|
2006-02-18 17:19:16 +01:00
|
|
|
|
|
|
|
# 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)
|
2006-02-20 09:34:02 +01:00
|
|
|
--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
|
2006-02-18 17:19:16 +01:00
|
|
|
eval select
|
2006-02-20 09:34:02 +01:00
|
|
|
(@a:=load_file("$MYSQLTEST_VARDIR/tmp/mix_innodb_myisam_binlog.output"))
|
2006-02-18 17:19:16 +01:00
|
|
|
is not null;
|
|
|
|
--replace_result $MYSQL_TEST_DIR MYSQL_TEST_DIR
|
|
|
|
eval select
|
2006-11-28 13:26:15 +01:00
|
|
|
@a like "%#%error_code=0%ROLLBACK/*!*/;%ROLLBACK /* added by mysqlbinlog */;%",
|
2006-02-18 17:19:16 +01:00
|
|
|
@a not like "%#%error_code=%error_code=%";
|
2006-02-18 21:08:41 +01:00
|
|
|
drop table t1, t2;
|