Fix for BUG##5714 "Insert into MyISAM table and select ... for update]":

the fact that the transaction log is empty does not mean we're not in a transaction
(it could be BEGIN; SELECT * FOR UPDATE FROM ibtable: then we don't want to commit now, even if
the statement is a MyISAM update).
With a testcase.


mysql-test/r/mix_innodb_myisam_binlog.result:
  result update
mysql-test/t/mix_innodb_myisam_binlog.test:
  test update for a new bug
sql/log.cc:
  The fact that the transaction log is empty does not mean we're not in a transaction
  (it could be BEGIN; SELECT * FOR UPDATE: then we don't want to commit now).

1 files changed, 32 insertions, 0 deletions

diff --git a/mysql-test/t/mix_innodb_myisam_binlog.test b/mysql-test/t/mix_innodb_myisam_binlog.test
index be45c2c3133..5f3b778c61a 100644
--- a/mysql-test/t/mix_innodb_myisam_binlog.test
+++ b/mysql-test/t/mix_innodb_myisam_binlog.test
@@ -175,4 +175,36 @@ select a from t1 order by a; # check that savepoints work :)
 
 show binlog events from 79;
 
+# Test for BUG#5714, where a MyISAM update in the transaction used to
+# release row-level locks in InnoDB
+
+connect (con3,localhost,root,,);
+
+connection con3;
+delete from t1;
+delete from t2;
+--disable_warnings
+alter table t2 type=MyISAM;
+--enable_warnings
+insert into t1 values (1);
+begin;
+select * from t1 for update;
+
+connection con2;
+select (@before:=unix_timestamp())*0; # always give repeatable output
+begin;
+send select * from t1 for update;
+
+connection con3;
+insert into t2 values (20);
+
+connection con2;
+--error 1205
+reap;
+select (@after:=unix_timestamp())*0; # always give repeatable output
+# verify that innodb_lock_wait_timeout was exceeded. When there was
+# the bug, the reap would return immediately after the insert into t2.
+select (@after-@before) >= 2;
+
+# cleanup
 drop table t1,t2;