- 12 Nov, 2010 5 commits
-
-
Dmitry Lenev authored
HANDLER and FLUSH TABLES WITH READ LOCK" and bug #54673 "It takes too long to get readlock for 'FLUSH TABLES WITH READ LOCK'". Disable execution of flush_read_lock.test on embedded server. This test uses too many statements which are not supported by embedded server.
-
Konstantin Osipov authored
network when a query was slow. When a query is slow, sent a special flag to the client indicating this fact. Add a test case. Implement review comments.
-
Jon Olav Hauglid authored
Text conflict in mysql-test/suite/perfschema/r/dml_setup_instruments.result Text conflict in mysql-test/suite/perfschema/r/global_read_lock.result Text conflict in mysql-test/suite/perfschema/r/server_init.result Text conflict in mysql-test/suite/perfschema/t/global_read_lock.test Text conflict in mysql-test/suite/perfschema/t/server_init.test
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
--with-comment correctly Properly convert --with-comment do not uppercase it, quote as it might contain spaces.
-
- 11 Nov, 2010 7 commits
-
-
Dmitry Lenev authored
bug #57006 "Deadlock between HANDLER and FLUSH TABLES WITH READ LOCK" and bug #54673 "It takes too long to get readlock for 'FLUSH TABLES WITH READ LOCK'". The first bug manifested itself as a deadlock which occurred when a connection, which had some table open through HANDLER statement, tried to update some data through DML statement while another connection tried to execute FLUSH TABLES WITH READ LOCK concurrently. What happened was that FTWRL in the second connection managed to perform first step of GRL acquisition and thus blocked all upcoming DML. After that it started to wait for table open through HANDLER statement to be flushed. When the first connection tried to execute DML it has started to wait for GRL/the second connection creating deadlock. The second bug manifested itself as starvation of FLUSH TABLES WITH READ LOCK statements in cases when there was a constant stream of concurrent DML statements (in two or more connections). This has happened because requests for protection against GRL which were acquired by DML statements were ignoring presence of pending GRL and thus the latter was starved. This patch solves both these problems by re-implementing GRL using metadata locks. Similar to the old implementation acquisition of GRL in new implementation is two-step. During the first step we block all concurrent DML and DDL statements by acquiring global S metadata lock (each DML and DDL statement acquires global IX lock for its duration). During the second step we block commits by acquiring global S lock in COMMIT namespace (commit code acquires global IX lock in this namespace). Note that unlike in old implementation acquisition of protection against GRL in DML and DDL is semi-automatic. We assume that any statement which should be blocked by GRL will either open and acquires write-lock on tables or acquires metadata locks on objects it is going to modify. For any such statement global IX metadata lock is automatically acquired for its duration. The first problem is solved because waits for GRL become visible to deadlock detector in metadata locking subsystem and thus deadlocks like one in the first bug become impossible. The second problem is solved because global S locks which are used for GRL implementation are given preference over IX locks which are acquired by concurrent DML (and we can switch to fair scheduling in future if needed). Important change: FTWRL/GRL no longer blocks DML and DDL on temporary tables. Before this patch behavior was not consistent in this respect: in some cases DML/DDL statements on temporary tables were blocked while in others they were not. Since the main use cases for FTWRL are various forms of backups and temporary tables are not preserved during backups we have opted for consistently allowing DML/DDL on temporary tables during FTWRL/GRL. Important change: This patch changes thread state names which are used when DML/DDL of FTWRL is waiting for global read lock. It is now either "Waiting for global read lock" or "Waiting for commit lock" depending on the stage on which FTWRL is. Incompatible change: To solve deadlock in events code which was exposed by this patch we have to replace LOCK_event_metadata mutex with metadata locks on events. As result we have to prohibit DDL on events under LOCK TABLES. This patch also adds extensive test coverage for interaction of DML/DDL and FTWRL. Performance of new and old global read lock implementations in sysbench tests were compared. There were no significant difference between new and old implementations.
-
Sunanda Menon authored
-
Sunanda Menon authored
( Based on review comments)
-
Sergey Vojtovich authored
-
Sergey Vojtovich authored
-
Dmitry Shulga authored
-
Dmitry Shulga authored
in different default schema. In strict mode, when data truncation or conversion happens, THD::killed is set to THD::KILL_BAD_DATA. This is abuse of KILL mechanism to guarantee that execution of statement is aborted. The stored procedures execution, on the other hand, upon detection that a connection was killed, would terminate immediately, without trying to restore the caller's context, in particular, restore the caller's current schema. The fix is, when terminating a stored procedure execution, to only bypass cleanup if the entire connection was killed, not in case of other forms of KILL.
-
- 10 Nov, 2010 8 commits
-
-
Vladislav Vaintroub authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
- added missing DBUG_RETURN - fixed whitespace according to coding style.
-
Oystein Grovlen authored
This bug was introduced in this revision: kostja@sun.com-20100727102553-b4n2ojcyfj79l2x7 ("A pre-requisite patch for the fix for Bug#52044.") It happens because close_thread_tables() is now called in open_and_lock_tables upon failure. Hence, table is no longer open when optimizer tries to do cleanup. Fix: Make sure to do cleanup in st_select_lex_unit::prepare() upon failure. This way, cleanup() is called before tables are released.
-
Dmitry Shulga authored
-
Dmitry Shulga authored
ALTER TABLE RENAME, DISABLE KEYS. The code of ALTER TABLE RENAME, DISABLE KEYS could issue a commit while holding LOCK_open mutex. This is a regression introduced by the fix for Bug 54453. This failed an assert guarding us against a potential deadlock with connections trying to execute FLUSH TABLES WITH READ LOCK. The fix is to move acquisition of LOCK_open outside the section that issues ha_autocommit_or_rollback(). LOCK_open is taken to protect against concurrent operations with .frms and the table definition cache, and doesn't need to cover the call to commit. A test case added to innodb_mysql.test. The patch is to be null-merged to 5.5, which already has 54453 null-merged to it.
-
Dmitry Shulga authored
-
Dmitry Shulga authored
-
- 09 Nov, 2010 9 commits
-
-
Davi Arnaut authored
The problem was that the scheduler function used to handle a new user connection could use the ER() macro without having a THD object bound to the current thread. The crash would happen whenever the function failed to create a new thread to handle a user connection. Thread creation can fail due to lack or limit of available resources. The solution is to simply use the ER_THD() macro instead and pass to it the THD object which would be bound to the connection. Fix was tested manually. In a test case, it is too cumbersome to inject a error in this context.
-
Davi Arnaut authored
-
Davi Arnaut authored
Quoting from the bug report: The pstack library has been included in MySQL since version 4.0.0. It's useless and should be removed. Details: According to its own documentation, pstack only works on Linux on x86 in 32 bit mode and requires LinuxThreads and a statically linked binary. It doesn't really support any Linux from 2003 or later and doesn't work on any other OS. The --enable-pstack option is thus deprecated and has no effect.
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Horst.Hunger authored
-
Bjorn Munch authored
-
Alexander Barkov authored
-
Anitha Gopi authored
Bug#58041 : Created separate per push and daily collections for 5.5-bugteam. Moved rpl_binlog_row to daily. Run just main suite for ps_row and embedded per push. Other suites run daily
-
- 08 Nov, 2010 11 commits
-
-
Marc Alff authored
-
Marc Alff authored
-
Horst.Hunger authored
-
Horst.Hunger authored
-
Jon Olav Hauglid authored
No conflicts
-
Sven Sandberg authored
-
Jon Olav Hauglid authored
-
Jon Olav Hauglid authored
GCOV builds were broken after the patch for Bug#57933 which added add -Wdeclaration-after-statement to gcc builds. This patch fixes: stacktrace.c:328: warning: ISO C90 forbids mixed declarations and code No test case added.
-
Jon Olav Hauglid authored
No conflicts
-
Jon Olav Hauglid authored
GCOV builds were broken after the patch for Bug#57933 which added add -Wdeclaration-after-statement to gcc builds. This patch fixes: stacktrace.c:328: warning: ISO C90 forbids mixed declarations and code No test case added.
-
Anitha Gopi authored
Bug#58041 : Moved rpl_binlog_row to daily. Run just main suite for ps_row and embedded per push. Other suites run daily
-