diff options
| author | Konstantin Osipov <kostja@sun.com> | 2010-04-28 17:43:25 +0400 |
|---|---|---|
| committer | Konstantin Osipov <kostja@sun.com> | 2010-04-28 17:43:25 +0400 |
| commit | 3789b2af0a1eb2a7538f6a5eaadf6e32e640f719 (patch) | |
| tree | ec12f2c3c173b277e0cd683ec035116f9e9ea3ef /mysql-test/r/lock_sync.result | |
| parent | 1ab519d91f2be200493d2ab085c87b7c640e395e (diff) | |
| download | mariadb-git-3789b2af0a1eb2a7538f6a5eaadf6e32e640f719.tar.gz | |
Bug#46947 "Embedded SELECT without FOR UPDATE is causing a lock"
Update the result file to minor tweaks of the comments in the
test case.
Diffstat (limited to 'mysql-test/r/lock_sync.result')
| -rw-r--r-- | mysql-test/r/lock_sync.result | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/mysql-test/r/lock_sync.result b/mysql-test/r/lock_sync.result index 299b5546716..e6265f1cb5e 100644 --- a/mysql-test/r/lock_sync.result +++ b/mysql-test/r/lock_sync.result @@ -439,14 +439,14 @@ Success: 'set @a:= f7()' doesn't allow concurrent inserts into 't1'. # doesn't modify data and reads a table # through a view. # -# Since such statement is written to the binary log and +# Since such statement is written to the binary log and # should be serialized with concurrent statements affecting # the data it uses. Therefore it should take a strong lock on # the table it reads. Success: 'insert into t3 values (f6() + 5)' doesn't allow concurrent inserts into 't1'. Success: 'insert into t3 values (f7() + 5)' doesn't allow concurrent inserts into 't1'. # -# 4.9 SELECT which uses a stored function which +# 4.9 SELECT which uses a stored function which # modifies data and reads tables through a view. # # Since a call to such function is written to the binary log @@ -457,7 +457,7 @@ Success: 'select f9()' doesn't allow concurrent inserts into 't1'. # # 4.10 SELECT which uses a stored function which doesn't modify # data and reads a table indirectly, by calling another -# function. +# function. # # In theory, calls to such functions won't get into the binary # log and thus don't need to acquire strong locks. But in practice @@ -508,7 +508,7 @@ Success: 'insert into t2 values (f13((select i+10 from t1 where i=1)))' doesn't # # Since neither this statement nor its components are # written to the binary log, there is no need to take -# strong locks on the data read it reads. +# strong locks on the data it reads. Success: 'call p2(@a)' allows concurrent inserts into 't1'. # # 5.2 Function that modifes data and uses CALL, @@ -543,7 +543,7 @@ Success: 'insert into t2 values (f15()+5)' doesn't allow concurrent inserts into # Since this statement is written to the binary log it should # be serialized with concurrent statements affecting the data # it uses. Therefore, it should take strong locks on the data -# it reads. +# it reads. Success: 'insert into t4 values (2)' doesn't allow concurrent inserts into 't1'. # # 6.2 Statement invoking a trigger that reads table through |