An error occurred fetching the project authors.
- 14 Apr, 2010 1 commit
-
-
Vasil Dimov authored
to mysql-test/
-
- 08 Jan, 2009 1 commit
-
-
Davi Arnaut authored
The problem is that a mysql connection instance is not thread-safe and reentrant, meaning that it can't be used concurrently and can't be re-entered while it's already running. This applies for any form of the server (embedded or not), but this rule can be violated in a test case if the test sends a new command without waiting for the result of previous command that was sent asynchronously and this can lead to hangs when over a network or to crashes under embedded server as the server query execution path will be re-entered concurrently with the same connection structure. The solution is to rework the test case so that the aforementioned rule is obeyed. mysql-test/t/innodb_bug38231.test: Remove con3 as it is not necessary to reproduce the test case and might cause problems as there is no guarantee on which LOCK TABLE request will succeed first. Also, wait for statement result before sending a new one on the same connection.
-
- 14 Dec, 2008 2 commits
-
-
Timothy Smith authored
resulted in a duplicate test case for bug 38231.
-
Timothy Smith authored
Bug#38231: Innodb crash in lock_reset_all_on_table() on TRUNCATE + LOCK / UNLOCK branches/5.1: Fix Bug#38231 Innodb crash in lock_reset_all_on_table() on TRUNCATE + LOCK / UNLOCK In TRUNCATE TABLE and discard tablespace: do not remove table-level S and X locks and do not assert on such locks not being wait locks. Leave such locks alone. Approved by: Heikki (rb://14)
-