summaryrefslogtreecommitdiff
path: root/mysql-test/r/innodb_mysql_lock2.result
diff options
context:
space:
mode:
authorSergei Golubchik <serg@mariadb.org>2014-10-16 00:30:29 +0200
committerSergei Golubchik <serg@mariadb.org>2014-10-16 00:30:29 +0200
commit1e79138459038c39c85239a825bf1727ef43c156 (patch)
tree88f725551c0f061487fde0ee5a6c0ea471b24abc /mysql-test/r/innodb_mysql_lock2.result
parent7aed441963823191e94da3df069e123dc8794eee (diff)
parent42f359f9827340bf430a9f1a0bda9b059951ea08 (diff)
downloadmariadb-git-1e79138459038c39c85239a825bf1727ef43c156.tar.gz
Merge branch 'bb-10.1-merge' into 10.1mariadb-10.1.1
Diffstat (limited to 'mysql-test/r/innodb_mysql_lock2.result')
-rw-r--r--mysql-test/r/innodb_mysql_lock2.result55
1 files changed, 29 insertions, 26 deletions
diff --git a/mysql-test/r/innodb_mysql_lock2.result b/mysql-test/r/innodb_mysql_lock2.result
index 17dd747de6f..54203c140a2 100644
--- a/mysql-test/r/innodb_mysql_lock2.result
+++ b/mysql-test/r/innodb_mysql_lock2.result
@@ -331,13 +331,14 @@ Success: 'update v2 set j= j-10 where j = 3' takes shared row locks on 't1'.
# 4.1 SELECT/SET with a stored function which does not
# modify data and uses SELECT in its turn.
#
-# In theory there is no need to take row locks on the table
+# There is no need to take row locks on the table
# being selected from in SF as the call to such function
-# won't get into the binary log. In practice, however, we
-# discover that fact too late in the process to be able to
-# affect the decision what locks should be taken.
-# Hence, strong locks are taken in this case.
-Success: 'select f1()' takes shared row locks on 't1'.
+# won't get into the binary log.
+#
+# However in practice innodb takes strong lock on tables
+# being selected from within SF, when SF is called from
+# non SELECT statements like 'set' statement below.
+Success: 'select f1()' doesn't take row locks on 't1'.
Success: 'set @a:= f1()' takes shared row locks on 't1'.
#
# 4.2 INSERT (or other statement which modifies data) with
@@ -364,13 +365,15 @@ Success: 'set @a:= f2()' takes shared row locks on 't1'.
# modify data and reads a table through subselect
# in a control construct.
#
-# Again, in theory a call to this function won't get to the
-# binary log and thus no locking is needed. But in practice
-# we don't detect this fact early enough (get_lock_type_for_table())
-# to avoid taking row locks.
-Success: 'select f3()' takes shared row locks on 't1'.
+# Call to this function won't get to the
+# binary log and thus no locking is needed.
+#
+# However in practice innodb takes strong lock on tables
+# being selected from within SF, when SF is called from
+# non SELECT statements like 'set' statement below.
+Success: 'select f3()' doesn't take row locks on 't1'.
Success: 'set @a:= f3()' takes shared row locks on 't1'.
-Success: 'select f4()' takes shared row locks on 't1'.
+Success: 'select f4()' doesn't take row locks on 't1'.
Success: 'set @a:= f4()' takes shared row locks on 't1'.
#
# 4.5. INSERT (or other statement which modifies data) with
@@ -398,13 +401,15 @@ Success: 'set @a:= f5()' takes shared row locks on 't1'.
# doesn't modify data and reads tables through
# a view.
#
-# Once again, in theory, calls to such functions won't
-# get into the binary log and thus don't need row
-# locks. But in practice this fact is discovered
-# too late to have any effect.
-Success: 'select f6()' takes shared row locks on 't1'.
+# Calls to such functions won't get into
+# the binary log and thus don't need row locks.
+#
+# However in practice innodb takes strong lock on tables
+# being selected from within SF, when SF is called from
+# non SELECT statements like 'set' statement below.
+Success: 'select f6()' doesn't take row locks on 't1'.
Success: 'set @a:= f6()' takes shared row locks on 't1'.
-Success: 'select f7()' takes shared row locks on 't1'.
+Success: 'select f7()' doesn't take row locks on 't1'.
Success: 'set @a:= f7()' takes shared row locks on 't1'.
#
# 4.8 INSERT which uses stored function which
@@ -431,10 +436,9 @@ Success: 'select f9()' takes shared row locks on 't1'.
# data and reads a table indirectly, by calling another
# function.
#
-# In theory, calls to such functions won't get into the binary
-# log and thus don't need to acquire row locks. But in practice
-# this fact is discovered too late to have any effect.
-Success: 'select f10()' takes shared row locks on 't1'.
+# Calls to such functions won't get into the binary
+# log and thus don't need to acquire row locks.
+Success: 'select f10()' doesn't take row locks on 't1'.
#
# 4.11 INSERT which uses a stored function which doesn't modify
# data and reads a table indirectly, by calling another
@@ -494,10 +498,9 @@ Success: 'select f14()' takes shared row locks on 't1'.
# 5.3 SELECT that calls a function that doesn't modify data and
# uses a CALL statement that reads a table via SELECT.
#
-# In theory, calls to such functions won't get into the binary
-# log and thus don't need to acquire row locks. But in practice
-# this fact is discovered too late to have any effect.
-Success: 'select f15()' takes shared row locks on 't1'.
+# Calls to such functions won't get into the binary
+# log and thus don't need to acquire row locks.
+Success: 'select f15()' doesn't take row locks on 't1'.
#
# 5.4 INSERT which calls function which doesn't modify data and
# uses CALL statement which reads table through SELECT.