2003-09-09 19:06:50 +02:00
|
|
|
drop table if exists t1, t2;
|
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;
|
2005-03-16 02:32:47 +01:00
|
|
|
show binlog events from 98;
|
2003-12-20 00:38:30 +01:00
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
2005-03-16 02:32:47 +01:00
|
|
|
master-bin.000001 98 Query 1 # use `test`; BEGIN
|
2005-03-25 14:51:17 +01:00
|
|
|
master-bin.000001 166 Query 1 # use `test`; insert into t1 values(1)
|
|
|
|
master-bin.000001 253 Query 1 # use `test`; insert into t2 select * from t1
|
2005-04-04 21:43:58 +02:00
|
|
|
master-bin.000001 347 Xid 1 # COMMIT /* xid=8 */
|
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;
|
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;
|
2003-09-12 04:54:12 +02:00
|
|
|
Warnings:
|
|
|
|
Warning 1196 Some non-transactional changed tables couldn't be rolled back
|
2005-03-16 02:32:47 +01:00
|
|
|
show binlog events from 98;
|
2003-12-20 00:38:30 +01:00
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
2005-03-16 02:32:47 +01:00
|
|
|
master-bin.000001 98 Query 1 # use `test`; BEGIN
|
2005-03-25 14:51:17 +01:00
|
|
|
master-bin.000001 166 Query 1 # use `test`; insert into t1 values(2)
|
|
|
|
master-bin.000001 253 Query 1 # use `test`; insert into t2 select * from t1
|
|
|
|
master-bin.000001 347 Query 1 # use `test`; ROLLBACK
|
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;
|
2003-09-12 04:54:12 +02:00
|
|
|
Warnings:
|
|
|
|
Warning 1196 Some non-transactional changed 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
|
|
|
commit;
|
2005-03-16 02:32:47 +01:00
|
|
|
show binlog events from 98;
|
2003-12-20 00:38:30 +01:00
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
2005-03-16 02:32:47 +01:00
|
|
|
master-bin.000001 98 Query 1 # use `test`; BEGIN
|
2005-03-25 14:51:17 +01:00
|
|
|
master-bin.000001 166 Query 1 # use `test`; insert into t1 values(3)
|
|
|
|
master-bin.000001 253 Query 1 # use `test`; savepoint my_savepoint
|
|
|
|
master-bin.000001 338 Query 1 # use `test`; insert into t1 values(4)
|
|
|
|
master-bin.000001 425 Query 1 # use `test`; insert into t2 select * from t1
|
|
|
|
master-bin.000001 519 Query 1 # use `test`; rollback to savepoint my_savepoint
|
2005-04-04 21:43:58 +02:00
|
|
|
master-bin.000001 616 Xid 1 # COMMIT /* xid=25 */
|
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-12 04:54:12 +02:00
|
|
|
Warnings:
|
|
|
|
Warning 1196 Some non-transactional changed tables couldn't be rolled back
|
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;
|
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
|
|
|
a
|
|
|
|
5
|
|
|
|
7
|
2005-03-16 02:32:47 +01:00
|
|
|
show binlog events from 98;
|
2003-12-20 00:38:30 +01:00
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
2005-03-16 02:32:47 +01:00
|
|
|
master-bin.000001 98 Query 1 # use `test`; BEGIN
|
2005-03-25 14:51:17 +01:00
|
|
|
master-bin.000001 166 Query 1 # use `test`; insert into t1 values(5)
|
|
|
|
master-bin.000001 253 Query 1 # use `test`; savepoint my_savepoint
|
|
|
|
master-bin.000001 338 Query 1 # use `test`; insert into t1 values(6)
|
|
|
|
master-bin.000001 425 Query 1 # use `test`; insert into t2 select * from t1
|
|
|
|
master-bin.000001 519 Query 1 # use `test`; rollback to savepoint my_savepoint
|
|
|
|
master-bin.000001 616 Query 1 # use `test`; insert into t1 values(7)
|
2005-04-04 21:43:58 +02:00
|
|
|
master-bin.000001 703 Xid 1 # COMMIT /* xid=37 */
|
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);
|
|
|
|
get_lock("a",10)
|
|
|
|
1
|
|
|
|
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
|
|
|
select get_lock("a",10);
|
|
|
|
get_lock("a",10)
|
|
|
|
1
|
2005-11-18 05:17:49 +01:00
|
|
|
show binlog events from 98;
|
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
|
|
|
master-bin.000001 98 Query 1 # use `test`; BEGIN
|
|
|
|
master-bin.000001 166 Query 1 # use `test`; insert into t1 values(8)
|
|
|
|
master-bin.000001 253 Query 1 # use `test`; insert into t2 select * from t1
|
|
|
|
master-bin.000001 347 Query 1 # use `test`; ROLLBACK
|
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(9);
|
|
|
|
insert into t2 select * from t1;
|
2005-03-16 02:32:47 +01:00
|
|
|
show binlog events from 98;
|
2003-12-20 00:38:30 +01:00
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
2005-03-16 02:32:47 +01:00
|
|
|
master-bin.000001 98 Query 1 # use `test`; insert into t1 values(9)
|
2005-04-04 21:43:58 +02:00
|
|
|
master-bin.000001 185 Xid 1 # COMMIT /* xid=60 */
|
2005-03-25 14:51:17 +01:00
|
|
|
master-bin.000001 212 Query 1 # use `test`; insert into t2 select * from t1
|
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);
|
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;
|
2005-03-16 02:32:47 +01:00
|
|
|
show binlog events from 98;
|
2003-12-20 00:38:30 +01:00
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
2005-03-16 02:32:47 +01:00
|
|
|
master-bin.000001 98 Query 1 # use `test`; insert into t1 values(10)
|
2005-04-04 21:43:58 +02:00
|
|
|
master-bin.000001 186 Xid 1 # COMMIT /* xid=66 */
|
2005-03-25 14:51:17 +01:00
|
|
|
master-bin.000001 213 Query 1 # use `test`; insert into t2 select * from t1
|
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;
|
2005-03-16 02:32:47 +01:00
|
|
|
show binlog events from 98;
|
2003-12-20 00:38:30 +01:00
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
2005-03-16 02:32:47 +01:00
|
|
|
master-bin.000001 98 Query 1 # use `test`; insert into t1 values(10)
|
2005-04-04 21:43:58 +02:00
|
|
|
master-bin.000001 186 Xid 1 # COMMIT /* xid=66 */
|
2005-03-25 14:51:17 +01:00
|
|
|
master-bin.000001 213 Query 1 # use `test`; insert into t2 select * from t1
|
|
|
|
master-bin.000001 307 Query 1 # use `test`; BEGIN
|
|
|
|
master-bin.000001 375 Query 1 # use `test`; insert into t1 values(11)
|
2005-04-04 21:43:58 +02:00
|
|
|
master-bin.000001 463 Xid 1 # COMMIT /* xid=68 */
|
2003-12-10 05:31:42 +01:00
|
|
|
alter table t2 engine=INNODB;
|
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;
|
2005-03-16 02:32:47 +01:00
|
|
|
show binlog events from 98;
|
2003-12-20 00:38:30 +01:00
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
2005-03-16 02:32:47 +01:00
|
|
|
master-bin.000001 98 Query 1 # use `test`; BEGIN
|
2005-03-25 14:51:17 +01:00
|
|
|
master-bin.000001 166 Query 1 # use `test`; insert into t1 values(12)
|
|
|
|
master-bin.000001 254 Query 1 # use `test`; insert into t2 select * from t1
|
2005-04-04 21:43:58 +02:00
|
|
|
master-bin.000001 348 Xid 1 # COMMIT /* xid=78 */
|
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;
|
2005-03-16 02:32:47 +01:00
|
|
|
show binlog events from 98;
|
2003-12-20 00:38:30 +01:00
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
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;
|
2005-03-16 02:32:47 +01:00
|
|
|
show binlog events from 98;
|
2003-12-20 00:38:30 +01:00
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
2005-03-16 02:32:47 +01:00
|
|
|
master-bin.000001 98 Query 1 # use `test`; BEGIN
|
2005-03-25 14:51:17 +01:00
|
|
|
master-bin.000001 166 Query 1 # use `test`; insert into t1 values(14)
|
2005-04-04 21:43:58 +02:00
|
|
|
master-bin.000001 254 Xid 1 # COMMIT /* xid=94 */
|
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;
|
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
|
|
|
a
|
|
|
|
16
|
|
|
|
18
|
2005-03-16 02:32:47 +01:00
|
|
|
show binlog events from 98;
|
2004-11-12 20:24:16 +01:00
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
2005-03-16 02:32:47 +01:00
|
|
|
master-bin.000001 98 Query 1 # use `test`; BEGIN
|
2005-03-25 14:51:17 +01:00
|
|
|
master-bin.000001 166 Query 1 # use `test`; insert into t1 values(16)
|
|
|
|
master-bin.000001 254 Query 1 # use `test`; insert into t1 values(18)
|
2005-04-04 21:43:58 +02:00
|
|
|
master-bin.000001 342 Xid 1 # COMMIT /* xid=105 */
|
2004-11-04 19:19:23 +01:00
|
|
|
delete from t1;
|
|
|
|
delete from t2;
|
|
|
|
alter table t2 type=MyISAM;
|
|
|
|
insert into t1 values (1);
|
|
|
|
begin;
|
|
|
|
select * from t1 for update;
|
|
|
|
a
|
|
|
|
1
|
|
|
|
select (@before:=unix_timestamp())*0;
|
|
|
|
(@before:=unix_timestamp())*0
|
|
|
|
0
|
|
|
|
begin;
|
2006-10-03 15:33:44 +02:00
|
|
|
select * from t1 for update;
|
2004-11-04 19:19:23 +01:00
|
|
|
insert into t2 values (20);
|
2004-11-12 16:44:17 +01:00
|
|
|
ERROR HY000: Lock wait timeout exceeded; try restarting transaction
|
2004-11-04 19:19:23 +01:00
|
|
|
select (@after:=unix_timestamp())*0;
|
|
|
|
(@after:=unix_timestamp())*0
|
|
|
|
0
|
|
|
|
select (@after-@before) >= 2;
|
|
|
|
(@after-@before) >= 2
|
|
|
|
1
|
2003-09-09 19:06:50 +02:00
|
|
|
drop table t1,t2;
|
2005-11-15 21:38:06 +01:00
|
|
|
commit;
|
|
|
|
begin;
|
|
|
|
create temporary table ti (a int) engine=innodb;
|
|
|
|
rollback;
|
|
|
|
Warnings:
|
|
|
|
Warning 1196 Some non-transactional changed tables couldn't be rolled back
|
|
|
|
insert into ti values(1);
|
|
|
|
set autocommit=0;
|
|
|
|
create temporary table t1 (a int) engine=myisam;
|
|
|
|
commit;
|
|
|
|
insert t1 values (1);
|
|
|
|
rollback;
|
2005-11-18 05:17:49 +01:00
|
|
|
Warnings:
|
|
|
|
Warning 1196 Some non-transactional changed tables couldn't be rolled back
|
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);
|
2005-11-17 05:17:38 +01:00
|
|
|
select get_lock("lock1",60);
|
|
|
|
get_lock("lock1",60)
|
|
|
|
1
|
2005-11-18 05:17:49 +01:00
|
|
|
show binlog events from 98;
|
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
|
|
|
master-bin.000001 98 Query 1 # use `test`; BEGIN
|
|
|
|
master-bin.000001 166 Query 1 # use `test`; insert into t1 values(16)
|
|
|
|
master-bin.000001 254 Query 1 # use `test`; insert into t1 values(18)
|
|
|
|
master-bin.000001 342 Xid 1 # COMMIT /* xid=105 */
|
|
|
|
master-bin.000001 369 Query 1 # use `test`; delete from t1
|
|
|
|
master-bin.000001 446 Xid 1 # COMMIT /* xid=114 */
|
|
|
|
master-bin.000001 473 Query 1 # use `test`; delete from t2
|
|
|
|
master-bin.000001 550 Xid 1 # COMMIT /* xid=115 */
|
|
|
|
master-bin.000001 577 Query 1 # use `test`; alter table t2 type=MyISAM
|
|
|
|
master-bin.000001 666 Query 1 # use `test`; insert into t1 values (1)
|
|
|
|
master-bin.000001 754 Xid 1 # COMMIT /* xid=117 */
|
|
|
|
master-bin.000001 781 Query 1 # use `test`; insert into t2 values (20)
|
|
|
|
master-bin.000001 870 Query 1 # use `test`; drop table t1,t2
|
|
|
|
master-bin.000001 949 Query 1 # use `test`; create temporary table ti (a int) engine=innodb
|
|
|
|
master-bin.000001 1059 Query 1 # use `test`; insert into ti values(1)
|
|
|
|
master-bin.000001 1146 Xid 1 # COMMIT /* xid=132 */
|
|
|
|
master-bin.000001 1173 Query 1 # use `test`; create temporary table t1 (a int) engine=myisam
|
|
|
|
master-bin.000001 1283 Query 1 # use `test`; insert t1 values (1)
|
|
|
|
master-bin.000001 1366 Query 1 # use `test`; create table t0 (n int)
|
|
|
|
master-bin.000001 1452 Query 1 # use `test`; insert t0 select * from t1
|
|
|
|
master-bin.000001 1541 Query 1 # use `test`; insert into t0 select GET_LOCK("lock1",null)
|
|
|
|
master-bin.000001 1648 Query 1 # use `test`; create table t2 (n int) engine=innodb
|
|
|
|
master-bin.000001 1748 Query 1 # use `test`; DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `test`.`t1`,`test`.`ti`
|
2005-11-15 21:38:06 +01:00
|
|
|
do release_lock("lock1");
|
|
|
|
drop table t0,t2;
|
2006-02-18 17:19:16 +01:00
|
|
|
reset master;
|
|
|
|
create table t1 (a int) engine=innodb;
|
|
|
|
create table t2 (a int) engine=myisam;
|
|
|
|
select get_lock("a",10);
|
|
|
|
get_lock("a",10)
|
|
|
|
1
|
|
|
|
begin;
|
|
|
|
insert into t1 values(8);
|
|
|
|
insert into t2 select * from t1;
|
|
|
|
select get_lock("a",10);
|
|
|
|
get_lock("a",10)
|
|
|
|
1
|
|
|
|
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;
|
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
|
|
|
|
1
|
|
|
|
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-11-28 13:26:15 +01:00
|
|
|
@a like "%#%error_code=0%ROLLBACK/*!*/;%ROLLBACK /* added by mysqlbinlog */;%" @a not like "%#%error_code=%error_code=%"
|
2006-02-18 17:19:16 +01:00
|
|
|
1 1
|
2006-02-18 21:08:41 +01:00
|
|
|
drop table t1, t2;
|