Below is the list of changes that have just been committed into a local
5.1 repository of kostja. When kostja does a push these changes
will be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
ChangeSet@stripped, 2008-02-07 17:17:09+03:00, kostja@dipika.(none) +26 -0
A fix and a test case for Bug#12713 "Error in a stored function called from
a SELECT doesn't cause ROLLBACK of statem".
The idea of the fix is to ensure that we always commit the current
statement at the end of dispatch_command(). In order to not issue
redundant disc syncs, an optimization of the two-phase commit
protocol is implemented to bypass the two phase commit if
the transaction is read-only.
mysql-test/include/commit.inc@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none) +742
-0
New BitKeeper file ``mysql-test/include/commit.inc''
mysql-test/include/commit.inc@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none) +0 -0
mysql-test/r/commit_1innodb.result@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none)
+889 -0
New BitKeeper file ``mysql-test/r/commit_1innodb.result''
mysql-test/r/commit_1innodb.result@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none)
+0 -0
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result@stripped, 2008-02-07
17:17:02+03:00, kostja@dipika.(none) +1 -2
Update test results.
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result@stripped, 2008-02-07
17:17:02+03:00, kostja@dipika.(none) +1 -3
Update test results.
mysql-test/suite/rpl_ndb/t/disabled.def@stripped, 2008-02-07 17:17:02+03:00,
kostja@dipika.(none) +2 -0
Disable the tests, for which this changeset reveals a bug:
the injector thread does not always add 'statement commit' to the
rows injected in circular replication set up.
To be investigated separately.
mysql-test/t/commit_1innodb.test@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none) +6
-0
New BitKeeper file ``mysql-test/t/commit_1innodb.test''
mysql-test/t/commit_1innodb.test@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none) +0
-0
sql/ha_ndbcluster_binlog.cc@stripped, 2008-02-07 17:17:02+03:00, kostja@dipika.(none) +1 -0
Add close_thread_tables() to run_query: this ensures
that all tables are closed and there is no pending statement transaction.
sql/handler.cc@stripped, 2008-02-07 17:17:02+03:00, kostja@dipika.(none) +553 -62
Implement optimisation of read-only transactions.
If a transaction consists only of DML statements that do not change
data, we do not perform a two-phase commit for it
(run one phase commit only).
sql/handler.h@stripped, 2008-02-07 17:17:02+03:00, kostja@dipika.(none) +113 -9
Implement optimisation of read-only transactions.
If a transaction consists only of DML statements that do not change
data, we do not perform a two-phase commit for it
(run one phase commit only).
sql/log.cc@stripped, 2008-02-07 17:17:03+03:00, kostja@dipika.(none) +10 -0
Mark the binlog transaction read-write whenever it's started.
We never read from binlog, so it's safe and least intrusive to add
this mark up here.
sql/log_event.cc@stripped, 2008-02-07 17:17:03+03:00, kostja@dipika.(none) +1 -1
Update to the new layout of thd->transaction.
sql/rpl_injector.cc@stripped, 2008-02-07 17:17:03+03:00, kostja@dipika.(none) +20 -0
Always commit statement transaction before committing the global one.
sql/sp.cc@stripped, 2008-02-07 17:17:03+03:00, kostja@dipika.(none) +17 -3
Ad comments.
sql/sp_head.cc@stripped, 2008-02-07 17:17:03+03:00, kostja@dipika.(none) +1 -0
Add comments.
sql/sql_base.cc@stripped, 2008-02-07 17:17:03+03:00, kostja@dipika.(none) +28 -30
Commit transaction at the end of the statement. Always.
sql/sql_class.cc@stripped, 2008-02-07 17:17:03+03:00, kostja@dipika.(none) +2 -2
Update thd_ha_data to return the right pointer in the new layout.
Fix select_dumpvar::send_data to properly return operation status.
A test case from commit.inc would lead to an assertion failure in the
diagnostics area (double assignment). Not test otherwise by the test suite.
sql/sql_class.h@stripped, 2008-02-07 17:17:03+03:00, kostja@dipika.(none) +30 -2
Implement a new layout of storage engine transaction info in which
it is easy to access all members related to the handlerton only
based on ht->slot.
sql/sql_cursor.cc@stripped, 2008-02-07 17:17:03+03:00, kostja@dipika.(none) +3 -2
Update to the new layout of thd->transaction.
sql/sql_delete.cc@stripped, 2008-02-07 17:17:03+03:00, kostja@dipika.(none) +17 -21
Remove wrong and now redundant calls to ha_autocommit_or_rollback.
The transaction is committed in one place, at the end of the statement.
Remove calls to mysql_unlock_tables, since some engines count locks
and commit statement transaction in unlock_tables(), which essentially
equates mysql_unlock_tables to ha_autocommit_or_rollback.
Previously it was necessary to unlock tables soon because we wanted
to avoid sending of 'ok' packet to the client under locked tables.
This is no longer necessary, since OK packet is also sent from one place
at the end of transaction.
sql/sql_insert.cc@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none) +15 -27
Remove wrong and now redundant calls to ha_autocommit_or_rollback.
The transaction is committed in one place, at the end of the statement.
Remove calls to mysql_unlock_tables, since some engines count locks
and commit statement transaction in unlock_tables(), which essentially
equates mysql_unlock_tables to ha_autocommit_or_rollback.
Previously it was necessary to unlock tables soon because we wanted
to avoid sending of 'ok' packet to the client under locked tables.
This is no longer necessary, since OK packet is also sent from one place
at the end of transaction.
sql/sql_load.cc@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none) +0 -10
Remove wrong and now redundant calls to ha_autocommit_or_rollback.
The transaction is committed in one place, at the end of the statement.
Remove calls to mysql_unlock_tables, since some engines count locks
and commit statement transaction in unlock_tables(), which essentially
equates mysql_unlock_tables to ha_autocommit_or_rollback.
Previously it was necessary to unlock tables soon because we wanted
to avoid sending of 'ok' packet to the client under locked tables.
This is no longer necessary, since OK packet is also sent from one place
at the end of transaction.
sql/sql_parse.cc@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none) +10 -17
Implement optimisation of read-only transactions: bypass 2-phase
commit for them.
Always commit statement transaction before commiting the global one.
Fix an unrelated crash in check_table_access, when called from
information_schema.
sql/sql_partition.cc@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none) +21 -17
Partitions commit at the end of a DDL operation.
Make sure that send_ok() is done only if the commit has succeeded.
sql/sql_table.cc@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none) +12 -9
Use ha_autocommit_or_rollback and end_active_trans everywhere.
Add end_trans to mysql_admin_table, so that it leaves no pending
transaction.
sql/sql_udf.cc@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none) +8 -1
Remvove a redundant call to close_thread_tables()
sql/sql_update.cc@stripped, 2008-02-07 17:17:04+03:00, kostja@dipika.(none) +1 -28
Remove wrong and now redundant calls to ha_autocommit_or_rollback.
The transaction is committed in one place, at the end of the statement.
Remove calls to mysql_unlock_tables, since some engines count locks
and commit statement transaction in unlock_tables(), which essentially
equates mysql_unlock_tables to ha_autocommit_or_rollback.
Previously it was necessary to unlock tables soon because we wanted
to avoid sending of 'ok' packet to the client under locked tables.
This is no longer necessary, since OK packet is also sent from one place
at the end of transaction.
diff -Nrup a/mysql-test/include/commit.inc b/mysql-test/include/commit.inc
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/mysql-test/include/commit.inc 2008-02-07 17:17:04 +03:00
@@ -0,0 +1,742 @@
+## Bug#12713 (Error in a stored function called from a SELECT doesn't cause
+## ROLLBACK of statem)
+
+##
+## Pre-Requisites :
+## - $engine_type should be set
+##
+
+set sql_mode=no_engine_substitution;
+eval set storage_engine = $engine_type;
+set autocommit=1;
+
+--disable_warnings
+drop table if exists t1;
+drop table if exists t2;
+drop table if exists t3;
+drop function if exists f2;
+drop procedure if exists bug12713_call;
+drop procedure if exists bug12713_dump_spvars;
+drop procedure if exists dummy;
+--enable_warnings
+
+create table t1 (a int);
+create table t2 (a int unique);
+create table t3 (a int);
+
+# a workaround for Bug#32633: Can not create any routine if
+# SQL_MODE=no_engine_substitution
+
+set sql_mode=default;
+
+insert into t1 (a) values (1), (2);
+insert into t3 (a) values (1), (2);
+
+delimiter |;
+
+## Cause a failure every time
+create function f2(x int) returns int
+begin
+ insert into t2 (a) values (x);
+ insert into t2 (a) values (x);
+ return x;
+end|
+
+delimiter ;|
+
+set autocommit=0;
+
+flush status;
+##============================================================================
+## Design notes
+##
+## In each case, statement rollback is expected.
+## for transactional engines, the rollback should be properly executed
+## for non transactional engines, the rollback may cause warnings.
+##
+## The test pattern is as follows
+## - insert 1000+N
+## - statement with a side effect, that fails to insert N twice
+## - a statement rollback is expected (expecting 1 row 1000+N only) in t2
+## - a rollback is performed
+## - expecting a clean table t2.
+##============================================================================
+
+insert into t2 (a) values (1001);
+--error ER_DUP_ENTRY
+insert into t1 (a) values (f2(1));
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1002);
+--error ER_DUP_ENTRY
+insert into t3 (a) select f2(2) from t1;
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1003);
+--error ER_DUP_ENTRY
+update t1 set a= a + f2(3);
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1004);
+--error ER_DUP_ENTRY
+update t1, t3 set t1.a = 0, t3.a = 0 where (f2(4) = 4) and (t1.a = t3.a);
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1005);
+--error ER_DUP_ENTRY
+delete from t1 where (a = f2(5));
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1006);
+--error ER_DUP_ENTRY
+delete from t1, t3 using t1, t3 where (f2(6) = 6) ;
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1007);
+--error ER_DUP_ENTRY
+replace t1 values (f2(7));
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1008);
+--error ER_DUP_ENTRY
+replace into t3 (a) select f2(8) from t1;
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1009);
+--error ER_DUP_ENTRY
+select f2(9) from t1 ;
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1010);
+--error ER_DUP_ENTRY
+show databases where (f2(10) = 10);
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1011);
+--error ER_DUP_ENTRY
+show tables where (f2(11) = 11);
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1012);
+--error ER_DUP_ENTRY
+show triggers where (f2(12) = 12);
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1013);
+--error ER_DUP_ENTRY
+show table status where (f2(13) = 13);
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1014);
+--error ER_DUP_ENTRY
+show open tables where (f2(14) = 14);
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1015);
+--error ER_DUP_ENTRY
+show columns in mysql.proc where (f2(15) = 15);
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1016);
+--error ER_DUP_ENTRY
+show status where (f2(16) = 16);
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1017);
+--error ER_DUP_ENTRY
+show variables where (f2(17) = 17);
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1018);
+--error ER_DUP_ENTRY
+show charset where (f2(18) = 18);
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1019);
+--error ER_DUP_ENTRY
+show collation where (f2(19) = 19);
+select * from t2;
+rollback;
+select * from t2;
+
+--echo # We need at least one procedure to make sure the WHERE clause is
+--echo # evaluated
+create procedure dummy() begin end;
+insert into t2 (a) values (1020);
+--error ER_DUP_ENTRY
+show procedure status where (f2(20) = 20);
+select * from t2;
+rollback;
+select * from t2;
+drop procedure dummy;
+
+insert into t2 (a) values (1021);
+--error ER_DUP_ENTRY
+show function status where (f2(21) = 21);
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1022);
+prepare stmt from "insert into t1 (a) values (f2(22))";
+--error ER_DUP_ENTRY
+execute stmt;
+select * from t2;
+rollback;
+select * from t2;
+
+insert into t2 (a) values (1023);
+do (f2(23));
+select * from t2;
+rollback;
+select * from t2;
+
+## Please note :
+## This will insert a record 1024 in t1 (statement commit)
+## This will insert a record 24 in t1 (statement commit)
+## then will rollback the second insert only (24) (statement rollback)
+## then will rollback the complete transaction (transaction rollback)
+
+delimiter |;
+
+create procedure bug12713_call ()
+begin
+ insert into t2 (a) values (24);
+ insert into t2 (a) values (24);
+end|
+
+delimiter ;|
+
+insert into t2 (a) values (1024);
+--error ER_DUP_ENTRY
+call bug12713_call();
+select * from t2;
+rollback;
+select * from t2;
+
+--echo =======================================================================
+--echo Testing select_to_file
+--echo =======================================================================
+
+insert into t2 (a) values (1025);
+
+--replace_result $MYSQLTEST_VARDIR ..
+--error ER_DUP_ENTRY
+eval select f2(25) into outfile "$MYSQLTEST_VARDIR/tmp/dml.out" from t1;
+select * from t2;
+rollback;
+select * from t2;
+--remove_file $MYSQLTEST_VARDIR/tmp/dml.out
+
+insert into t2 (a) values (1026);
+--replace_result $MYSQLTEST_VARDIR ..
+--error ER_DUP_ENTRY
+eval load data infile "../std_data_ln/words.dat" into table t1 (a) set a:=f2(26);
+
+select * from t2;
+rollback;
+select * from t2;
+
+--echo =======================================================================
+--echo Testing select_dumpvar
+--echo =======================================================================
+
+insert into t2 (a) values (1027);
+--error ER_DUP_ENTRY
+select f2(27) into @foo;
+select * from t2;
+rollback;
+select * from t2;
+
+--echo =======================================================================
+--echo Testing Select_fetch_into_spvars
+--echo =======================================================================
+
+delimiter |;
+
+create procedure bug12713_dump_spvars ()
+begin
+ declare foo int;
+
+ declare continue handler for sqlexception
+ begin
+ select "Exception trapped";
+ end;
+
+ select f2(28) into foo;
+ select * from t2;
+end|
+
+delimiter ;|
+
+insert into t2 (a) values (1028);
+call bug12713_dump_spvars ();
+rollback;
+select * from t2;
+
+--echo =======================================================================
+--echo Cleanup
+--echo =======================================================================
+
+set autocommit=default;
+
+drop table t1;
+drop table t2;
+drop table t3;
+drop function f2;
+drop procedure bug12713_call;
+drop procedure bug12713_dump_spvars;
+--echo #
+--echo # Bug#12713 Error in a stored function called from a SELECT doesn't
+--echo # cause ROLLBACK of statem
+--echo #
+--echo # Verify that two-phase commit is not issued for read-only
+--echo # transactions.
+--echo #
+--echo # Verify that two-phase commit is issued for read-write transactions,
+--echo # even if the change is done inside a stored function called from
+--echo # SELECT or SHOW statement.
+--echo #
+set autocommit=0;
+--disable_warnings
+drop table if exists t1;
+drop table if exists t2;
+drop function if exists f1;
+drop procedure if exists p_verify_status_increment;
+--enable_warnings
+
+set sql_mode=no_engine_substitution;
+create table t1 (a int unique);
+create table t2 (a int) engine=myisam;
+set sql_mode=default;
+--echo #
+--echo # An auxiliary procedure to track Handler_prepare and Handler_commit
+--echo # statistics.
+--echo #
+delimiter |;
+create procedure
+p_verify_status_increment(commit_inc_mixed int, prepare_inc_mixed int,
+ commit_inc_row int, prepare_inc_row int)
+begin
+ declare commit_inc int;
+ declare prepare_inc int;
+ declare old_commit_count int default ifnull(@commit_count, 0);
+ declare old_prepare_count int default ifnull(@prepare_count, 0);
+ declare c_res int;
+# Use a cursor to have just one access to I_S instead of 2, it is very slow
+# and amounts for over 90% of test CPU time
+ declare c cursor for
+ select variable_value
+ from information_schema.session_status
+ where variable_name='Handler_commit' or variable_name='Handler_prepare'
+ order by variable_name;
+
+ if @@global.binlog_format = 'ROW' then
+ set commit_inc= commit_inc_row;
+ set prepare_inc= prepare_inc_row;
+ else
+ set commit_inc= commit_inc_mixed;
+ set prepare_inc= prepare_inc_mixed;
+ end if;
+
+ open c;
+ fetch c into c_res;
+ set @commit_count=c_res;
+ fetch c into c_res;
+ set @prepare_count=c_res;
+ close c;
+
+ if old_commit_count + commit_inc <> @commit_count then
+ select concat("Expected commit increment: ", commit_inc,
+ " actual: ", @commit_count - old_commit_count)
+ as 'ERROR';
+ elseif old_prepare_count + prepare_inc <> @prepare_count then
+ select concat("Expected prepare increment: ", prepare_inc,
+ " actual: ", @prepare_count - old_prepare_count)
+ as 'ERROR';
+ else
+ select '' as 'SUCCESS';
+ end if;
+end|
+delimiter ;|
+--echo # Reset Handler_commit and Handler_prepare counters
+flush status;
+--echo #
+--echo # 1. Read-only statement: SELECT
+--echo #
+select * from t1;
+call p_verify_status_increment(1, 0, 1, 0);
+commit;
+call p_verify_status_increment(1, 0, 1, 0);
+
+--echo # 2. Read-write statement: INSERT, insert 1 row.
+--echo #
+insert into t1 (a) values (1);
+call p_verify_status_increment(2, 2, 2, 2);
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+
+--echo # 3. Read-write statement: UPDATE, update 1 row.
+--echo #
+update t1 set a=2;
+call p_verify_status_increment(2, 2, 2, 2);
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+
+--echo # 4. Read-write statement: UPDATE, update 0 rows, 1 row matches WHERE
+--echo #
+--echo # Note the wrong Handler_prepare/Handler_commit count is due to
+--echo # Bug#29157 "UPDATE, changed rows incorrect" and
+--echo # Bug#Bug #33846 UPDATE word:Wrong 'Changed rows' if InnoDB, unique
+--echo # key and no rows qualify WHERE
+--echo #
+update t1 set a=2;
+call p_verify_status_increment(2, 2, 2, 2);
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+
+--echo # 5. Read-write statement: UPDATE, update 0 rows, 0 rows match WHERE
+--echo #
+--echo # In mixed replication mode, there is a read-only transaction
+--echo # in InnoDB and also the statement is written to the binary log.
+--echo # So we have two commits but no 2pc, since the first engine's
+--echo # transaction is read-only.
+--echo # In the row level replication mode, we only have the read-only
+--echo # transaction in InnoDB and nothing is written to the binary log.
+--echo #
+update t1 set a=3 where a=1;
+call p_verify_status_increment(2, 0, 1, 0);
+commit;
+call p_verify_status_increment(2, 0, 1, 0);
+
+--echo # 6. Read-write statement: DELETE, delete 0 rows.
+--echo #
+delete from t1 where a=1;
+call p_verify_status_increment(2, 0, 1, 0);
+commit;
+call p_verify_status_increment(2, 0, 1, 0);
+
+--echo # 7. Read-write statement: DELETE, delete 1 row.
+--echo #
+delete from t1 where a=2;
+call p_verify_status_increment(2, 2, 2, 2);
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+
+--echo # 8. Read-write statement: unqualified DELETE
+--echo #
+--echo # In statement or mixed replication mode, we call
+--echo # handler::ha_delete_all_rows() and write statement text
+--echo # to the binary log. This results in two read-write transactions.
+--echo # In row level replication mode, we do not call
+--echo # handler::ha_delete_all_rows(), but delete rows one by one.
+--echo # Since there are no rows, nothing is written to the binary log.
+--echo # Thus we have just one read-only transaction in InnoDB.
+delete from t1;
+call p_verify_status_increment(2, 2, 1, 0);
+commit;
+call p_verify_status_increment(2, 2, 1, 0);
+
+--echo # 9. Read-write statement: REPLACE, change 1 row.
+--echo #
+replace t1 set a=1;
+call p_verify_status_increment(2, 2, 2, 2);
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+
+--echo # 10. Read-write statement: REPLACE, change 0 rows.
+--echo #
+replace t1 set a=1;
+call p_verify_status_increment(2, 2, 2, 2);
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+
+--echo # 11. Read-write statement: IODKU, change 1 row.
+--echo #
+insert t1 set a=1 on duplicate key update a=a+1;
+call p_verify_status_increment(2, 2, 2, 2);
+select * from t1;
+call p_verify_status_increment(1, 0, 1, 0);
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+
+--echo # 12. Read-write statement: IODKU, change 0 rows.
+--echo #
+insert t1 set a=2 on duplicate key update a=2;
+call p_verify_status_increment(1, 0, 1, 0);
+commit;
+call p_verify_status_increment(1, 0, 1, 0);
+
+--echo # 13. Read-write statement: INSERT IGNORE, change 0 rows.
+--echo #
+insert ignore t1 set a=2;
+call p_verify_status_increment(1, 0, 1, 0);
+commit;
+call p_verify_status_increment(1, 0, 1, 0);
+
+--echo # 14. Read-write statement: INSERT IGNORE, change 1 row.
+--echo #
+insert ignore t1 set a=1;
+call p_verify_status_increment(2, 2, 2, 2);
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+--echo # 15. Read-write statement: UPDATE IGNORE, change 0 rows.
+--echo #
+update ignore t1 set a=2 where a=1;
+call p_verify_status_increment(2, 2, 1, 0);
+commit;
+call p_verify_status_increment(2, 2, 1, 0);
+--echo #
+--echo # Create a stored function that modifies a
+--echo # non-transactional table. Demonstrate that changes in
+--echo # non-transactional tables do not affect the two phase commit
+--echo # algorithm.
+--echo #
+delimiter |;
+create function f1() returns int
+begin
+ insert t2 set a=2;
+ return 2;
+end|
+delimiter ;|
+call p_verify_status_increment(0, 0, 0, 0);
+
+--echo # 16. A function changes non-trans-table.
+--echo #
+select f1();
+call p_verify_status_increment(0, 0, 0, 0);
+commit;
+call p_verify_status_increment(0, 0, 0, 0);
+
+--echo # 17. Read-only statement, a function changes non-trans-table.
+--echo #
+select f1() from t1;
+call p_verify_status_increment(1, 0, 1, 0);
+commit;
+call p_verify_status_increment(1, 0, 1, 0);
+
+--echo # 18. Read-write statement: UPDATE, change 0 (transactional) rows.
+--echo #
+select count(*) from t2;
+update t1 set a=2 where a=f1()+10;
+select count(*) from t2;
+call p_verify_status_increment(2, 0, 2, 0);
+commit;
+call p_verify_status_increment(2, 0, 2, 0);
+--echo #
+--echo # Replace the non-transactional table with a temporary
+--echo # transactional table. Demonstrate that a change to a temporary
+--echo # transactional table does not provoke 2-phase commit, although
+--echo # does trigger a commit and a binlog write (in statement mode).
+--echo #
+drop table t2;
+set sql_mode=no_engine_substitution;
+create temporary table t2 (a int);
+call p_verify_status_increment(0, 0, 0, 0);
+set sql_mode=default;
+--echo # 19. A function changes temp-trans-table.
+--echo #
+select f1();
+--echo # Two commits because a binary log record is written
+call p_verify_status_increment(2, 0, 1, 0);
+commit;
+call p_verify_status_increment(2, 0, 1, 0);
+
+--echo # 20. Read-only statement, a function changes non-trans-table.
+--echo #
+select f1() from t1;
+--echo # Two commits because a binary log record is written
+call p_verify_status_increment(2, 0, 1, 0);
+commit;
+call p_verify_status_increment(2, 0, 1, 0);
+
+--echo # 21. Read-write statement: UPDATE, change 0 (transactional) rows.
+--echo #
+update t1 set a=2 where a=f1()+10;
+call p_verify_status_increment(2, 0, 1, 0);
+commit;
+call p_verify_status_increment(2, 0, 1, 0);
+
+--echo # 22. DDL: ALTER TEMPORARY TABLE, should not cause a 2pc
+--echo #
+alter table t2 add column b int default 5;
+--echo # A commit is done internally by ALTER.
+call p_verify_status_increment(2, 0, 2, 0);
+commit;
+--echo # There is nothing left to commit
+call p_verify_status_increment(0, 0, 0, 0);
+
+--echo # 23. DDL: RENAME TEMPORARY TABLE, does not start a transaction
+--echo
+--echo # No test because of Bug#8729 "rename table fails on temporary table"
+
+--echo # 24. DDL: TRUNCATE TEMPORARY TABLE, does not start a transaction
+--echo
+truncate table t2;
+call p_verify_status_increment(2, 0, 2, 0);
+commit;
+--echo # There is nothing left to commit
+call p_verify_status_increment(0, 0, 0, 0);
+
+--echo # 25. Read-write statement: unqualified DELETE
+--echo
+delete from t2;
+call p_verify_status_increment(2, 0, 1, 0);
+commit;
+--echo # There is nothing left to commit
+call p_verify_status_increment(2, 0, 1, 0);
+
+--echo # 25. DDL: DROP TEMPORARY TABLE, does not start a transaction
+--echo #
+drop temporary table t2;
+call p_verify_status_increment(0, 0, 0, 0);
+commit;
+call p_verify_status_increment(0, 0, 0, 0);
+
+--echo # 26. Verify that SET AUTOCOMMIT issues an implicit commit
+--echo #
+insert t1 set a=3;
+call p_verify_status_increment(2, 2, 2, 2);
+set autocommit=1;
+call p_verify_status_increment(2, 2, 2, 2);
+rollback;
+select a from t1 where a=3;
+call p_verify_status_increment(1, 0, 1, 0);
+delete from t1 where a=3;
+call p_verify_status_increment(2, 2, 2, 2);
+commit;
+call p_verify_status_increment(0, 0, 0, 0);
+set autocommit=0;
+call p_verify_status_increment(0, 0, 0, 0);
+insert t1 set a=3;
+call p_verify_status_increment(2, 2, 2, 2);
+--echo # Sic: not actually changing the value of autocommit
+set autocommit=0;
+call p_verify_status_increment(0, 0, 0, 0);
+rollback;
+select a from t1 where a=3;
+call p_verify_status_increment(1, 0, 1, 0);
+
+--echo # 27. Savepoint management
+--echo #
+insert t1 set a=3;
+call p_verify_status_increment(2, 2, 2, 2);
+savepoint a;
+call p_verify_status_increment(0, 0, 0, 0);
+insert t1 set a=4;
+--echo # Sic: a bug. Binlog did not register itself this time.
+call p_verify_status_increment(1, 0, 1, 0);
+release savepoint a;
+rollback;
+call p_verify_status_increment(0, 0, 0, 0);
+select a from t1 where a=3;
+call p_verify_status_increment(1, 0, 1, 0);
+commit;
+call p_verify_status_increment(1, 0, 1, 0);
+
+--echo # 28. Read-write statement: DO
+--echo #
+create table t2 (a int);
+call p_verify_status_increment(0, 0, 0, 0);
+do (select f1() from t1 where a=2);
+call p_verify_status_increment(2, 2, 2, 2);
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+
+--echo # 29. Read-write statement: MULTI-DELETE
+--echo #
+delete t1, t2 from t1 join t2 on (t1.a=t2.a) where t1.a=2;
+commit;
+call p_verify_status_increment(4, 4, 4, 4);
+
+--echo # 30. Read-write statement: INSERT-SELECT, MULTI-UPDATE, REPLACE-SELECT
+--echo #
+insert into t2 select a from t1;
+commit;
+replace into t2 select a from t1;
+commit;
+call p_verify_status_increment(8, 8, 8, 8);
+#
+# Multi-update is one of the few remaining statements that still
+# locks the tables at prepare step (and hence starts the transaction.
+# Disable the PS protocol, since in this protocol we get a different
+# number of commmits (there is an extra commit after prepare
+#
+--disable_ps_protocol
+update t1, t2 set t1.a=4, t2.a=8 where t1.a=t2.a and t1.a=1;
+--enable_ps_protocol
+commit;
+call p_verify_status_increment(4, 4, 4, 4);
+
+--echo # 31. DDL: various DDL with transactional tables
+--echo #
+--echo # Sic: no table is created.
+create table if not exists t2 (a int) select 6 union select 7;
+--echo # Sic: first commits the statement, and then the transaction.
+call p_verify_status_increment(4, 4, 4, 4);
+create table t3 select a from t2;
+call p_verify_status_increment(4, 4, 4, 4);
+alter table t3 add column (b int);
+call p_verify_status_increment(2, 0, 2, 0);
+alter table t3 rename t4;
+call p_verify_status_increment(1, 0, 1, 0);
+rename table t4 to t3;
+call p_verify_status_increment(1, 0, 1, 0);
+truncate table t3;
+call p_verify_status_increment(2, 2, 2, 2);
+create view v1 as select * from t2;
+call p_verify_status_increment(1, 0, 1, 0);
+check table t1;
+call p_verify_status_increment(3, 0, 3, 0);
+--echo # Sic: after this bug is fixed, CHECK leaves no pending transaction
+commit;
+call p_verify_status_increment(0, 0, 0, 0);
+check table t1, t2, t3;
+call p_verify_status_increment(6, 0, 6, 0);
+commit;
+call p_verify_status_increment(0, 0, 0, 0);
+drop view v1;
+call p_verify_status_increment(0, 0, 0, 0);
+
+--echo #
+--echo # Cleanup
+--echo #
+drop table t1;
+drop procedure p_verify_status_increment;
+drop function f1;
diff -Nrup a/mysql-test/r/commit_1innodb.result b/mysql-test/r/commit_1innodb.result
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/mysql-test/r/commit_1innodb.result 2008-02-07 17:17:04 +03:00
@@ -0,0 +1,889 @@
+set sql_mode=no_engine_substitution;
+set storage_engine = InnoDB;
+set autocommit=1;
+drop table if exists t1;
+drop table if exists t2;
+drop table if exists t3;
+drop function if exists f2;
+drop procedure if exists bug12713_call;
+drop procedure if exists bug12713_dump_spvars;
+drop procedure if exists dummy;
+create table t1 (a int);
+create table t2 (a int unique);
+create table t3 (a int);
+set sql_mode=default;
+insert into t1 (a) values (1), (2);
+insert into t3 (a) values (1), (2);
+create function f2(x int) returns int
+begin
+insert into t2 (a) values (x);
+insert into t2 (a) values (x);
+return x;
+end|
+set autocommit=0;
+flush status;
+insert into t2 (a) values (1001);
+insert into t1 (a) values (f2(1));
+ERROR 23000: Duplicate entry '1' for key 'a'
+select * from t2;
+a
+1001
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1002);
+insert into t3 (a) select f2(2) from t1;
+ERROR 23000: Duplicate entry '2' for key 'a'
+select * from t2;
+a
+1002
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1003);
+update t1 set a= a + f2(3);
+ERROR 23000: Duplicate entry '3' for key 'a'
+select * from t2;
+a
+1003
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1004);
+update t1, t3 set t1.a = 0, t3.a = 0 where (f2(4) = 4) and (t1.a = t3.a);
+ERROR 23000: Duplicate entry '4' for key 'a'
+select * from t2;
+a
+1004
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1005);
+delete from t1 where (a = f2(5));
+ERROR 23000: Duplicate entry '5' for key 'a'
+select * from t2;
+a
+1005
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1006);
+delete from t1, t3 using t1, t3 where (f2(6) = 6) ;
+ERROR 23000: Duplicate entry '6' for key 'a'
+select * from t2;
+a
+1006
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1007);
+replace t1 values (f2(7));
+ERROR 23000: Duplicate entry '7' for key 'a'
+select * from t2;
+a
+1007
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1008);
+replace into t3 (a) select f2(8) from t1;
+ERROR 23000: Duplicate entry '8' for key 'a'
+select * from t2;
+a
+1008
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1009);
+select f2(9) from t1 ;
+ERROR 23000: Duplicate entry '9' for key 'a'
+select * from t2;
+a
+1009
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1010);
+show databases where (f2(10) = 10);
+ERROR 23000: Duplicate entry '10' for key 'a'
+select * from t2;
+a
+1010
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1011);
+show tables where (f2(11) = 11);
+ERROR 23000: Duplicate entry '11' for key 'a'
+select * from t2;
+a
+1011
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1012);
+show triggers where (f2(12) = 12);
+ERROR 23000: Duplicate entry '12' for key 'a'
+select * from t2;
+a
+1012
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1013);
+show table status where (f2(13) = 13);
+ERROR 23000: Duplicate entry '13' for key 'a'
+select * from t2;
+a
+1013
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1014);
+show open tables where (f2(14) = 14);
+ERROR 23000: Duplicate entry '14' for key 'a'
+select * from t2;
+a
+1014
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1015);
+show columns in mysql.proc where (f2(15) = 15);
+ERROR 23000: Duplicate entry '15' for key 'a'
+select * from t2;
+a
+1015
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1016);
+show status where (f2(16) = 16);
+ERROR 23000: Duplicate entry '16' for key 'a'
+select * from t2;
+a
+1016
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1017);
+show variables where (f2(17) = 17);
+ERROR 23000: Duplicate entry '17' for key 'a'
+select * from t2;
+a
+1017
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1018);
+show charset where (f2(18) = 18);
+ERROR 23000: Duplicate entry '18' for key 'a'
+select * from t2;
+a
+1018
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1019);
+show collation where (f2(19) = 19);
+ERROR 23000: Duplicate entry '19' for key 'a'
+select * from t2;
+a
+1019
+rollback;
+select * from t2;
+a
+# We need at least one procedure to make sure the WHERE clause is
+# evaluated
+create procedure dummy() begin end;
+insert into t2 (a) values (1020);
+show procedure status where (f2(20) = 20);
+ERROR 23000: Duplicate entry '20' for key 'a'
+select * from t2;
+a
+1020
+rollback;
+select * from t2;
+a
+drop procedure dummy;
+insert into t2 (a) values (1021);
+show function status where (f2(21) = 21);
+ERROR 23000: Duplicate entry '21' for key 'a'
+select * from t2;
+a
+1021
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1022);
+prepare stmt from "insert into t1 (a) values (f2(22))";
+execute stmt;
+ERROR 23000: Duplicate entry '22' for key 'a'
+select * from t2;
+a
+1022
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1023);
+do (f2(23));
+Warnings:
+Error 1062 Duplicate entry '23' for key 'a'
+select * from t2;
+a
+23
+1023
+rollback;
+select * from t2;
+a
+create procedure bug12713_call ()
+begin
+insert into t2 (a) values (24);
+insert into t2 (a) values (24);
+end|
+insert into t2 (a) values (1024);
+call bug12713_call();
+ERROR 23000: Duplicate entry '24' for key 'a'
+select * from t2;
+a
+24
+1024
+rollback;
+select * from t2;
+a
+=======================================================================
+Testing select_to_file
+=======================================================================
+insert into t2 (a) values (1025);
+select f2(25) into outfile "../tmp/dml.out" from t1;
+ERROR 23000: Duplicate entry '25' for key 'a'
+select * from t2;
+a
+1025
+rollback;
+select * from t2;
+a
+insert into t2 (a) values (1026);
+load data infile "../std_data_ln/words.dat" into table t1 (a) set a:=f2(26);
+ERROR 23000: Duplicate entry '26' for key 'a'
+select * from t2;
+a
+1026
+rollback;
+select * from t2;
+a
+=======================================================================
+Testing select_dumpvar
+=======================================================================
+insert into t2 (a) values (1027);
+select f2(27) into @foo;
+ERROR 23000: Duplicate entry '27' for key 'a'
+select * from t2;
+a
+1027
+rollback;
+select * from t2;
+a
+=======================================================================
+Testing Select_fetch_into_spvars
+=======================================================================
+create procedure bug12713_dump_spvars ()
+begin
+declare foo int;
+declare continue handler for sqlexception
+begin
+select "Exception trapped";
+end;
+select f2(28) into foo;
+select * from t2;
+end|
+insert into t2 (a) values (1028);
+call bug12713_dump_spvars ();
+Exception trapped
+Exception trapped
+a
+1028
+rollback;
+select * from t2;
+a
+=======================================================================
+Cleanup
+=======================================================================
+set autocommit=default;
+drop table t1;
+drop table t2;
+drop table t3;
+drop function f2;
+drop procedure bug12713_call;
+drop procedure bug12713_dump_spvars;
+#
+# Bug#12713 Error in a stored function called from a SELECT doesn't
+# cause ROLLBACK of statem
+#
+# Verify that two-phase commit is not issued for read-only
+# transactions.
+#
+# Verify that two-phase commit is issued for read-write transactions,
+# even if the change is done inside a stored function called from
+# SELECT or SHOW statement.
+#
+set autocommit=0;
+drop table if exists t1;
+drop table if exists t2;
+drop function if exists f1;
+drop procedure if exists p_verify_status_increment;
+set sql_mode=no_engine_substitution;
+create table t1 (a int unique);
+create table t2 (a int) engine=myisam;
+set sql_mode=default;
+#
+# An auxiliary procedure to track Handler_prepare and Handler_commit
+# statistics.
+#
+create procedure
+p_verify_status_increment(commit_inc_mixed int, prepare_inc_mixed int,
+commit_inc_row int, prepare_inc_row int)
+begin
+declare commit_inc int;
+declare prepare_inc int;
+declare old_commit_count int default ifnull(@commit_count, 0);
+declare old_prepare_count int default ifnull(@prepare_count, 0);
+declare c_res int;
+# Use a cursor to have just one access to I_S instead of 2, it is very slow
+# and amounts for over 90% of test CPU time
+declare c cursor for
+select variable_value
+from information_schema.session_status
+where variable_name='Handler_commit' or variable_name='Handler_prepare'
+ order by variable_name;
+if @@global.binlog_format = 'ROW' then
+set commit_inc= commit_inc_row;
+set prepare_inc= prepare_inc_row;
+else
+set commit_inc= commit_inc_mixed;
+set prepare_inc= prepare_inc_mixed;
+end if;
+open c;
+fetch c into c_res;
+set @commit_count=c_res;
+fetch c into c_res;
+set @prepare_count=c_res;
+close c;
+if old_commit_count + commit_inc <> @commit_count then
+select concat("Expected commit increment: ", commit_inc,
+" actual: ", @commit_count - old_commit_count)
+as 'ERROR';
+elseif old_prepare_count + prepare_inc <> @prepare_count then
+select concat("Expected prepare increment: ", prepare_inc,
+" actual: ", @prepare_count - old_prepare_count)
+as 'ERROR';
+else
+select '' as 'SUCCESS';
+end if;
+end|
+# Reset Handler_commit and Handler_prepare counters
+flush status;
+#
+# 1. Read-only statement: SELECT
+#
+select * from t1;
+a
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+# 2. Read-write statement: INSERT, insert 1 row.
+#
+insert into t1 (a) values (1);
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+# 3. Read-write statement: UPDATE, update 1 row.
+#
+update t1 set a=2;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+# 4. Read-write statement: UPDATE, update 0 rows, 1 row matches WHERE
+#
+# Note the wrong Handler_prepare/Handler_commit count is due to
+# Bug#29157 "UPDATE, changed rows incorrect" and
+# Bug#Bug #33846 UPDATE word:Wrong 'Changed rows' if InnoDB, unique
+# key and no rows qualify WHERE
+#
+update t1 set a=2;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+# 5. Read-write statement: UPDATE, update 0 rows, 0 rows match WHERE
+#
+# In mixed replication mode, there is a read-only transaction
+# in InnoDB and also the statement is written to the binary log.
+# So we have two commits but no 2pc, since the first engine's
+# transaction is read-only.
+# In the row level replication mode, we only have the read-only
+# transaction in InnoDB and nothing is written to the binary log.
+#
+update t1 set a=3 where a=1;
+call p_verify_status_increment(2, 0, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 0, 1, 0);
+SUCCESS
+
+# 6. Read-write statement: DELETE, delete 0 rows.
+#
+delete from t1 where a=1;
+call p_verify_status_increment(2, 0, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 0, 1, 0);
+SUCCESS
+
+# 7. Read-write statement: DELETE, delete 1 row.
+#
+delete from t1 where a=2;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+# 8. Read-write statement: unqualified DELETE
+#
+# In statement or mixed replication mode, we call
+# handler::ha_delete_all_rows() and write statement text
+# to the binary log. This results in two read-write transactions.
+# In row level replication mode, we do not call
+# handler::ha_delete_all_rows(), but delete rows one by one.
+# Since there are no rows, nothing is written to the binary log.
+# Thus we have just one read-only transaction in InnoDB.
+delete from t1;
+call p_verify_status_increment(2, 2, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 2, 1, 0);
+SUCCESS
+
+# 9. Read-write statement: REPLACE, change 1 row.
+#
+replace t1 set a=1;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+# 10. Read-write statement: REPLACE, change 0 rows.
+#
+replace t1 set a=1;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+# 11. Read-write statement: IODKU, change 1 row.
+#
+insert t1 set a=1 on duplicate key update a=a+1;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+select * from t1;
+a
+2
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+# 12. Read-write statement: IODKU, change 0 rows.
+#
+insert t1 set a=2 on duplicate key update a=2;
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+# 13. Read-write statement: INSERT IGNORE, change 0 rows.
+#
+insert ignore t1 set a=2;
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+# 14. Read-write statement: INSERT IGNORE, change 1 row.
+#
+insert ignore t1 set a=1;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+# 15. Read-write statement: UPDATE IGNORE, change 0 rows.
+#
+update ignore t1 set a=2 where a=1;
+call p_verify_status_increment(2, 2, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 2, 1, 0);
+SUCCESS
+
+#
+# Create a stored function that modifies a
+# non-transactional table. Demonstrate that changes in
+# non-transactional tables do not affect the two phase commit
+# algorithm.
+#
+create function f1() returns int
+begin
+insert t2 set a=2;
+return 2;
+end|
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+# 16. A function changes non-trans-table.
+#
+select f1();
+f1()
+2
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+# 17. Read-only statement, a function changes non-trans-table.
+#
+select f1() from t1;
+f1()
+2
+2
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+# 18. Read-write statement: UPDATE, change 0 (transactional) rows.
+#
+select count(*) from t2;
+count(*)
+3
+update t1 set a=2 where a=f1()+10;
+select count(*) from t2;
+count(*)
+5
+call p_verify_status_increment(2, 0, 2, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 0, 2, 0);
+SUCCESS
+
+#
+# Replace the non-transactional table with a temporary
+# transactional table. Demonstrate that a change to a temporary
+# transactional table does not provoke 2-phase commit, although
+# does trigger a commit and a binlog write (in statement mode).
+#
+drop table t2;
+set sql_mode=no_engine_substitution;
+create temporary table t2 (a int);
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+set sql_mode=default;
+# 19. A function changes temp-trans-table.
+#
+select f1();
+f1()
+2
+# Two commits because a binary log record is written
+call p_verify_status_increment(2, 0, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 0, 1, 0);
+SUCCESS
+
+# 20. Read-only statement, a function changes non-trans-table.
+#
+select f1() from t1;
+f1()
+2
+2
+# Two commits because a binary log record is written
+call p_verify_status_increment(2, 0, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 0, 1, 0);
+SUCCESS
+
+# 21. Read-write statement: UPDATE, change 0 (transactional) rows.
+#
+update t1 set a=2 where a=f1()+10;
+call p_verify_status_increment(2, 0, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 0, 1, 0);
+SUCCESS
+
+# 22. DDL: ALTER TEMPORARY TABLE, should not cause a 2pc
+#
+alter table t2 add column b int default 5;
+# A commit is done internally by ALTER.
+call p_verify_status_increment(2, 0, 2, 0);
+SUCCESS
+
+commit;
+# There is nothing left to commit
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+# 23. DDL: RENAME TEMPORARY TABLE, does not start a transaction
+
+# No test because of Bug#8729 "rename table fails on temporary table"
+# 24. DDL: TRUNCATE TEMPORARY TABLE, does not start a transaction
+
+truncate table t2;
+call p_verify_status_increment(2, 0, 2, 0);
+SUCCESS
+
+commit;
+# There is nothing left to commit
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+# 25. Read-write statement: unqualified DELETE
+
+delete from t2;
+call p_verify_status_increment(2, 0, 1, 0);
+SUCCESS
+
+commit;
+# There is nothing left to commit
+call p_verify_status_increment(2, 0, 1, 0);
+SUCCESS
+
+# 25. DDL: DROP TEMPORARY TABLE, does not start a transaction
+#
+drop temporary table t2;
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+# 26. Verify that SET AUTOCOMMIT issues an implicit commit
+#
+insert t1 set a=3;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+set autocommit=1;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+rollback;
+select a from t1 where a=3;
+a
+3
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+delete from t1 where a=3;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+commit;
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+set autocommit=0;
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+insert t1 set a=3;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+# Sic: not actually changing the value of autocommit
+set autocommit=0;
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+rollback;
+select a from t1 where a=3;
+a
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+# 27. Savepoint management
+#
+insert t1 set a=3;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+savepoint a;
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+insert t1 set a=4;
+# Sic: a bug. Binlog did not register itself this time.
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+release savepoint a;
+rollback;
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+select a from t1 where a=3;
+a
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+# 28. Read-write statement: DO
+#
+create table t2 (a int);
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+do (select f1() from t1 where a=2);
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+commit;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+# 29. Read-write statement: MULTI-DELETE
+#
+delete t1, t2 from t1 join t2 on (t1.a=t2.a) where t1.a=2;
+commit;
+call p_verify_status_increment(4, 4, 4, 4);
+SUCCESS
+
+# 30. Read-write statement: INSERT-SELECT, MULTI-UPDATE, REPLACE-SELECT
+#
+insert into t2 select a from t1;
+commit;
+replace into t2 select a from t1;
+commit;
+call p_verify_status_increment(8, 8, 8, 8);
+SUCCESS
+
+update t1, t2 set t1.a=4, t2.a=8 where t1.a=t2.a and t1.a=1;
+commit;
+call p_verify_status_increment(4, 4, 4, 4);
+SUCCESS
+
+# 31. DDL: various DDL with transactional tables
+#
+# Sic: no table is created.
+create table if not exists t2 (a int) select 6 union select 7;
+Warnings:
+Note 1050 Table 't2' already exists
+# Sic: first commits the statement, and then the transaction.
+call p_verify_status_increment(4, 4, 4, 4);
+SUCCESS
+
+create table t3 select a from t2;
+call p_verify_status_increment(4, 4, 4, 4);
+SUCCESS
+
+alter table t3 add column (b int);
+call p_verify_status_increment(2, 0, 2, 0);
+SUCCESS
+
+alter table t3 rename t4;
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+rename table t4 to t3;
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+truncate table t3;
+call p_verify_status_increment(2, 2, 2, 2);
+SUCCESS
+
+create view v1 as select * from t2;
+call p_verify_status_increment(1, 0, 1, 0);
+SUCCESS
+
+check table t1;
+Table Op Msg_type Msg_text
+test.t1 check status OK
+call p_verify_status_increment(3, 0, 3, 0);
+SUCCESS
+
+# Sic: after this bug is fixed, CHECK leaves no pending transaction
+commit;
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+check table t1, t2, t3;
+Table Op Msg_type Msg_text
+test.t1 check status OK
+test.t2 check status OK
+test.t3 check status OK
+call p_verify_status_increment(6, 0, 6, 0);
+SUCCESS
+
+commit;
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+drop view v1;
+call p_verify_status_increment(0, 0, 0, 0);
+SUCCESS
+
+#
+# Cleanup
+#
+drop table t1;
+drop procedure p_verify_status_increment;
+drop function f1;
diff -Nrup a/mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result
b/mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result
--- a/mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result 2007-10-14 00:12:45
+04:00
+++ b/mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result 2008-02-07 17:17:02
+03:00
@@ -373,7 +373,7 @@ master-bin.000001 # Write_rows # # table
master-bin.000001 # Query # # use `test`; BEGIN
master-bin.000001 # Table_map # # table_id: # (test.t2)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
-master-bin.000001 # Xid # # COMMIT /* XID */
+master-bin.000001 # Query # # use `test`; COMMIT
master-bin.000001 # Query # # use `test`; DROP TABLE t2
master-bin.000001 # Table_map # # table_id: # (test.t1)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
@@ -384,7 +384,6 @@ master-bin.000001 # Write_rows # # table
master-bin.000001 # Table_map # # table_id: # (test.t1)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
master-bin.000001 # Query # # use `test`; TRUNCATE table t2
-master-bin.000001 # Xid # # COMMIT /* XID */
master-bin.000001 # Table_map # # table_id: # (test.t1)
master-bin.000001 # Write_rows # # table_id: # flags: STMT_END_F
master-bin.000001 # Query # # use `test`; DROP TABLE `t1` /* generated by server */
diff -Nrup a/mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
b/mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
--- a/mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result 2007-10-14 00:12:46
+04:00
+++ b/mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result 2008-02-07 17:17:02
+03:00
@@ -244,7 +244,6 @@ master-bin.000001 # Query # # use `test`
master-bin.000001 # Query # # use `test`; drop table t1,t2
master-bin.000001 # Query # # use `test`; create temporary table ti (a int) engine=innodb
master-bin.000001 # Query # # use `test`; insert into ti values(1)
-master-bin.000001 # Xid # # COMMIT /* XID */
master-bin.000001 # Query # # use `test`; create temporary table t1 (a int) engine=myisam
master-bin.000001 # Query # # use `test`; insert t1 values (1)
master-bin.000001 # Query # # use `test`; create table t0 (n int)
@@ -349,11 +348,10 @@ master-bin.000001 # Query # # use `test`
master-bin.000001 # Query # # use `test`; INSERT INTO t1 values (8,8)
master-bin.000001 # Query # # use `test`; INSERT INTO t1 values (9,9)
master-bin.000001 # Query # # use `test`; TRUNCATE table t2
-master-bin.000001 # Xid # # COMMIT /* XID */
master-bin.000001 # Query # # use `test`; INSERT INTO t1 values (10,10)
master-bin.000001 # Query # # use `test`; BEGIN
master-bin.000001 # Query # # use `test`; INSERT INTO t2 values (100,100)
-master-bin.000001 # Xid # # COMMIT /* XID */
+master-bin.000001 # Query # # use `test`; COMMIT
master-bin.000001 # Query # # use `test`; DROP TABLE t1,t2
reset master;
create table t1 (a int) engine=innodb;
diff -Nrup a/mysql-test/suite/rpl_ndb/t/disabled.def
b/mysql-test/suite/rpl_ndb/t/disabled.def
--- a/mysql-test/suite/rpl_ndb/t/disabled.def 2007-12-11 13:51:00 +03:00
+++ b/mysql-test/suite/rpl_ndb/t/disabled.def 2008-02-07 17:17:02 +03:00
@@ -21,3 +21,5 @@ rpl_ndb_mix_innodb : Bug #32720
# the below testcase have been reworked to avoid the bug, test contains comment, keep bug
open
#rpl_ndb_dd_advance : Bug#25913 rpl_ndb_dd_advance fails randomly
+rpl_ndb_circular : Bug#33849 COMMIT event missing in cluster circular
replication.
+rpl_ndb_circular_simplex : Bug#33849 COMMIT event missing in cluster circular
replication.
diff -Nrup a/mysql-test/t/commit_1innodb.test b/mysql-test/t/commit_1innodb.test
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/mysql-test/t/commit_1innodb.test 2008-02-07 17:17:04 +03:00
@@ -0,0 +1,6 @@
+-- source include/have_log_bin.inc
+-- source include/have_innodb.inc
+
+let $engine_type = InnoDB;
+
+-- source include/commit.inc
diff -Nrup a/sql/ha_ndbcluster_binlog.cc b/sql/ha_ndbcluster_binlog.cc
--- a/sql/ha_ndbcluster_binlog.cc 2007-12-15 22:23:55 +03:00
+++ b/sql/ha_ndbcluster_binlog.cc 2008-02-07 17:17:02 +03:00
@@ -283,6 +283,7 @@ static void run_query(THD *thd, char *bu
thd_ndb->m_error_code,
(int) thd->is_error(), thd->is_slave_error);
}
+ close_thread_tables(thd);
/*
XXX: this code is broken. mysql_parse()/mysql_reset_thd_for_next_command()
can not be called from within a statement, and
diff -Nrup a/sql/handler.cc b/sql/handler.cc
--- a/sql/handler.cc 2008-01-25 20:37:27 +03:00
+++ b/sql/handler.cc 2008-02-07 17:17:02 +03:00
@@ -576,6 +576,295 @@ void ha_close_connection(THD* thd)
======================= TRANSACTIONS ===================================*/
/**
+ Transaction handling in the server
+ ==================================
+
+ In each client connection, MySQL maintains two transactional
+ states:
+ - a statement transaction,
+ - a standard, also called normal transaction.
+
+ Historical note
+ ---------------
+ "Statement transaction" is a non-standard term that comes
+ from the times when MySQL supported BerkeleyDB storage engine.
+
+ First of all, it should be said that in BerkeleyDB auto-commit
+ mode auto-commits operations that are atomic to the storage
+ engine itself, such as a write of a record, and are too
+ high-granular to be atomic from the application perspective
+ (MySQL). One SQL statement could involve many BerkeleyDB
+ auto-committed operations and thus BerkeleyDB auto-commit was of
+ little use to MySQL.
+
+ Secondly, instead of SQL standard savepoints, BerkeleyDB
+ provided the concept of "nested transactions". In a nutshell,
+ transactions could be arbitrarily nested, but when the parent
+ transaction was committed or aborted, all its child (nested)
+ transactions were handled committed or aborted as well.
+ Commit of a nested transaction, in turn, made its changes
+ visible, but not durable: it destroyed the nested transaction,
+ all its changes would become available to the parent and
+ currently active nested transactions of this parent.
+
+ So the mechanism of nested transactions was employed to
+ provide "all or nothing" guarantee of SQL statements
+ required by the standard.
+ A nested transaction would be created at start of each SQL
+ statement, and destroyed (committed or aborted) at statement
+ end. Such nested transaction was internally referred to as
+ a "statement transaction" and gave birth to the term.
+
+ <Historical note ends>
+
+ Since then a statement transaction is started for each statement
+ that accesses transactional tables or uses the binary log. If
+ the statement succeeds, the statement transaction is committed.
+ If the statement fails, the transaction is rolled back. Commits
+ of statement transactions are not durable -- each such
+ transaction is nested in the normal transaction, and if the
+ normal transaction is rolled back, the effects of all enclosed
+ statement transactions are undone as well. Technically,
+ a statement transaction can be viewed as a savepoint which is
+ maintained automatically in order to make effects of one
+ statement atomic.
+
+ The normal transaction is started by the user and is ended
+ usually upon a user request as well. The normal transaction
+ encloses transactions of all statements issued between
+ its beginning and its end.
+ In autocommit mode, the normal transaction is equivalent
+ to the statement transaction.
+
+ Since MySQL supports PSEA (pluggable storage engine
+ architecture), more than one transactional engine can be
+ active at a time. Hence transactions, from the server
+ point of view, are always distributed. In particular,
+ transactional state is maintained independently for each
+ engine. In order to commit a transaction the two phase
+ commit protocol is employed.
+
+ Not all statements are executed in context of a transaction.
+ Administrative and status information statements do not modify
+ engine data, and thus do not start a statement transaction and
+ also have no effect on the normal transaction. Examples of such
+ statements are SHOW STATUS and RESET SLAVE.
+
+ Similarly DDL statements are not transactional,
+ and therefore a transaction is [almost] never started for a DDL
+ statement. The difference between a DDL statement and a purely
+ administrative statement though is that a DDL statement always
+ commits the current transaction before proceeding, if there is
+ any.
+
+ At last, SQL statements that work with non-transactional
+ engines also have no effect on the transaction state of the
+ connection. Even though they are written to the binary log,
+ and the binary log is, overall, transactional, the writes
+ are done in "write-through" mode, directly to the binlog
+ file, followed with a OS cache sync, in other words,
+ bypassing the binlog undo log (translog).
+ They do not commit the current normal transaction.
+ A failure of a statement that uses non-transactional tables
+ would cause a rollback of the statement transaction, but
+ in case there no non-transactional tables are used,
+ no statement transaction is started.
+
+ Data layout
+ -----------
+
+ The server stores its transaction-related data in
+ thd->transaction. This structure has two members of type
+ THD_TRANS. These members correspond to the statement and
+ normal transactions respectively:
+
+ - thd->transaction.stmt contains a list of engines
+ that are participating in the given statement
+ - thd->transaction.all contains a list of engines that
+ have participated in any of the statement transactions started
+ within the context of the normal transaction.
+ Each element of the list contains a pointer to the storage
+ engine, engine-specific transactional data, and engine-specific
+ transaction flags.
+
+ In autocommit mode thd->transaction.all is empty.
+ Instead, data of thd->transaction.stmt is
+ used to commit/rollback the normal transaction.
+
+ The list of registered engines has a few important properties:
+ - no engine is registered in the list twice
+ - engines are present in the list a reverse temporal order --
+ new participants are always added to the beginning of the list.
+
+ Transaction life cycle
+ ----------------------
+
+ When a new connection is established, thd->transaction
+ members are initialized to an empty state.
+ If a statement uses any tables, all affected engines
+ are registered in the statement engine list. In
+ non-autocommit mode, the same engines are registered in
+ the normal transaction list.
+ At the end of the statement, the server issues a commit
+ or a roll back for all engines in the statement list.
+ At this point transaction flags of an engine, if any, are
+ propagated from the statement list to the list of the normal
+ transaction.
+ When commit/rollback is finished, the statement list is
+ cleared. It will be filled in again by the next statement,
+ and emptied again at the next statement's end.
+
+ The normal transaction is committed in a similar way
+ (by going over all engines in thd->transaction.all list)
+ but at different times:
+ - upon COMMIT SQL statement is issued by the user
+ - implicitly, by the server, at the beginning of a DDL statement
+ or SET AUTOCOMMIT={0|1} statement.
+
+ The normal transaction can be rolled back as well:
+ - if the user has requested so, by issuing ROLLBACK SQL
+ statement
+ - if one of the storage engines requested a rollback
+ by setting thd->transaction_rollback_request. This may
+ happen in case, e.g., when the transaction in the engine was
+ chosen a victim of the internal deadlock resolution algorithm
+ and rolled back internally. When such a situation happens, there
+ is little the server can do and the only option is to rollback
+ transactions in all other participating engines. In this case
+ the rollback is accompanied by an error sent to the user.
+
+ As follows from the use cases above, the normal transaction
+ is never committed when there is an outstanding statement
+ transaction. In most cases there is no conflict, since
+ commits of the normal transaction are issued by a stand-alone
+ administrative or DDL statement, thus no outstanding statement
+ transaction of the previous statement exists. Besides,
+ all statements that manipulate with the normal transaction
+ are prohibited in stored functions and triggers, therefore
+ no conflicting situation can occur in a sub-statement either.
+ The remaining rare cases when the server explicitly has
+ to commit the statement transaction prior to committing the normal
+ one cover error-handling scenarios (see for example
+ SQLCOM_LOCK_TABLES).
+
+ When committing a statement or a normal transaction, the server
+ either uses the two-phase commit protocol, or issues a commit
+ in each engine independently. The two-phase commit protocol
+ is used only if:
+ - all participating engines support two-phase commit (provide
+ handlerton::prepare PSEA API call) and
+ - transactions in at least two engines modify data (i.e. are
+ not read-only).
+
+ Note that the two phase commit is used for
+ statement transactions, even though they are not durable anyway.
+ This is done to ensure logical consistency of data in a multiple-
+ engine transaction.
+ For example, imagine that some day MySQL supports unique
+ constraint checks deferred till the end of statement. In such
+ case a commit in one of the engines may yield ER_DUP_KEY,
+ and MySQL should be able to gracefully abort statement
+ transactions of other participants.
+
+ After the normal transaction has been committed,
+ thd->transaction.all list is cleared.
+
+ When a connection is closed, the current normal transaction, if
+ any, is rolled back.
+
+ Roles and responsibilities
+ --------------------------
+
+ The server has no way to know that an engine participates in
+ the statement and a transaction has been started
+ in it unless the engine says so. Thus, in order to be
+ a part of a transaction, the engine must "register" itself.
+ This is done by invoking trans_register_ha() server call.
+ Normally the engine registers itself whenever handler::external_lock()
+ is called. trans_register_ha() can be invoked many times: if
+ an engine is already registered, the call does nothing.
+ In case autocommit is not set, the engine must register itself
+ twice -- both in the statement list and in the normal transaction
+ list.
+ In which list to register is a parameter of trans_register_ha().
+
+ Note, that although the registration interface in itself is
+ fairly clear, the current usage practice often leads to undesired
+ effects. E.g. since a call to trans_register_ha() in most engines
+ is embedded into implementation of handler::external_lock(), some
+ DDL statements start a transaction (at least from the server
+ point of view) even though they are not expected to. E.g.
+ CREATE TABLE does not start a transaction, since
+ handler::external_lock() is never called during CREATE TABLE. But
+ CREATE TABLE ... SELECT does, since handler::external_lock() is
+ called for the table that is being selected from. This has no
+ practical effects currently, but must be kept in mind
+ nevertheless.
+
+ Once an engine is registered, the server will do the rest
+ of the work.
+
+ During statement execution, whenever any of data-modifying
+ PSEA API methods is used, e.g. handler::write_row() or
+ handler::update_row(), the read-write flag is raised in the
+ statement transaction for the involved engine.
+ Currently All PSEA calls are "traced", and the data can not be
+ changed in a way other than issuing a PSEA call. Important:
+ unless this invariant is preserved the server will not know that
+ a transaction in a given engine is read-write and will not
+ involve the two-phase commit protocol!
+
+ At the end of a statement, server call
+ ha_autocommit_or_rollback() is invoked. This call in turn
+ invokes handlerton::prepare() for every involved engine.
+ Prepare is followed by a call to handlerton::commit_one_phase()
+ If a one-phase commit will suffice, handlerton::prepare() is not
+ invoked and the server only calls handlerton::commit_one_phase().
+ At statement commit, the statement-related read-write engine
+ flag is propagated to the corresponding flag in the normal
+ transaction. When the commit is complete, the list of registered
+ engines is cleared.
+
+ Rollback is handled in a similar fashion.
+
+ Additional notes on DDL and the normal transaction.
+ ---------------------------------------------------
+
+ DDLs and operations with non-transactional engines
+ do not "register" in thd->transaction lists, and thus do not
+ modify the transaction state. Besides, each DDL in
+ MySQL is prefixed with an implicit normal transaction commit
+ (a call to end_active_trans()), and thus leaves nothing
+ to modify.
+ However, as it has been pointed out with CREATE TABLE .. SELECT,
+ some DDL statements can start a *new* transaction.
+
+ Behaviour of the server in this case is currently badly
+ defined.
+ DDL statements use a form of "semantic" logging
+ to maintain atomicity: if CREATE TABLE .. SELECT failed,
+ the newly created table is deleted.
+ In addition, some DDL statements issue interim transaction
+ commits: e.g. ALTER TABLE issues a commit after data is copied
+ from the original table to the internal temporary table. Other
+ statements, e.g. CREATE TABLE ... SELECT do not always commit
+ after itself.
+ And finally there is a group of DDL statements such as
+ RENAME/DROP TABLE that doesn't start a new transaction
+ and doesn't commit.
+
+ This diversity makes it hard to say what will happen if
+ by chance a stored function is invoked during a DDL --
+ whether any modifications it makes will be committed or not
+ is not clear. Fortunately, SQL grammar of few DDLs allows
+ invocation of a stored function.
+
+ A consistent behaviour is perhaps to always commit the normal
+ transaction after all DDLs, just like the statement transaction
+ is always committed at the end of all statements.
+*/
+
+/**
Register a storage engine for a transaction.
Every storage engine MUST call this function when it starts
@@ -592,7 +881,7 @@ void ha_close_connection(THD* thd)
void trans_register_ha(THD *thd, bool all, handlerton *ht_arg)
{
THD_TRANS *trans;
- handlerton **ht;
+ Ha_trx_info *ha_info;
DBUG_ENTER("trans_register_ha");
DBUG_PRINT("enter",("%s", all ? "all" : "stmt"));
@@ -604,12 +893,13 @@ void trans_register_ha(THD *thd, bool al
else
trans= &thd->transaction.stmt;
- for (ht=trans->ht; *ht; ht++)
- if (*ht == ht_arg)
- DBUG_VOID_RETURN; /* already registered, return */
+ ha_info= thd->ha_data[ht_arg->slot].ha_info + static_cast<unsigned>(all);
+
+ if (ha_info->is_started())
+ DBUG_VOID_RETURN; /* already registered, return */
+
+ ha_info->register_ha(trans, ht_arg);
- trans->ht[trans->nht++]=ht_arg;
- DBUG_ASSERT(*ht == ht_arg);
trans->no_2pc|=(ht_arg->prepare==0);
if (thd->transaction.xid_state.xid.is_null())
thd->transaction.xid_state.xid.set(thd->query_id);
@@ -626,18 +916,19 @@ int ha_prepare(THD *thd)
{
int error=0, all=1;
THD_TRANS *trans=all ? &thd->transaction.all : &thd->transaction.stmt;
- handlerton **ht=trans->ht;
+ Ha_trx_info *ha_info= trans->ha_list;
DBUG_ENTER("ha_prepare");
#ifdef USING_TRANSACTIONS
- if (trans->nht)
+ if (ha_info)
{
- for (; *ht; ht++)
+ for (; ha_info; ha_info= ha_info->next())
{
int err;
+ handlerton *ht= ha_info->ht();
status_var_increment(thd->status_var.ha_prepare_count);
- if ((*ht)->prepare)
+ if (ht->prepare)
{
- if ((err= (*(*ht)->prepare)(*ht, thd, all)))
+ if ((err= ht->prepare(ht, thd, all)))
{
my_error(ER_ERROR_DURING_COMMIT, MYF(0), err);
ha_rollback_trans(thd, all);
@@ -649,7 +940,7 @@ int ha_prepare(THD *thd)
{
push_warning_printf(thd, MYSQL_ERROR::WARN_LEVEL_WARN,
ER_ILLEGAL_HA, ER(ER_ILLEGAL_HA),
- ha_resolve_storage_engine_name(*ht));
+ ha_resolve_storage_engine_name(ht));
}
}
}
@@ -658,6 +949,62 @@ int ha_prepare(THD *thd)
}
/**
+ Check if we can skip the two-phase commit.
+
+ A helper function to evaluate if two-phase commit is mandatory.
+ As a side effect, propagates the read-only/read-write flags
+ of the statement transaction to its enclosing normal transaction.
+
+ @retval TRUE we must run a two-phase commit. Returned
+ if we have at least two engines with read-write changes.
+ @retval FALSE Don't need two-phase commit. Even if we have two
+ transactional engines, we can run two independent
+ commits if changes in one of the engines are read-only.
+*/
+
+static
+bool
+ha_check_and_coalesce_trx_read_only(THD *thd, Ha_trx_info *ha_list,
+ bool all)
+{
+ /* The number of storage engines that have actual changes. */
+ unsigned rw_ha_count= 0;
+ Ha_trx_info *ha_info;
+
+ for (ha_info= ha_list; ha_info; ha_info= ha_info->next())
+ {
+ if (ha_info->is_trx_read_write())
+ ++rw_ha_count;
+
+ if (! all)
+ {
+ Ha_trx_info *ha_info_all=
&thd->ha_data[ha_info->ht()->slot].ha_info[1];
+ DBUG_ASSERT(ha_info != ha_info_all);
+ /*
+ Merge read-only/read-write information about statement
+ transaction to its enclosing normal transaction. Do this
+ only if in a real transaction -- that is, if we know
