MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:dlenev Date:March 15 2007 8:30am
Subject:bk commit into 4.1 tree (dlenev:1.2618) BUG#25966
View as plain text  
Below is the list of changes that have just been committed into a local
4.1 repository of dlenev. When dlenev does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html

ChangeSet@stripped, 2007-03-15 11:30:17+03:00, dlenev@stripped +1 -0
  Fix for bug #25966 "2MB per second endless memory consumption after LOCK
  TABLE ... WRITE".
  
  CPU hogging occured when connection which had to wait for table lock was
  serviced by thread which previously serviced connection that was killed
  (note that connections can reuse threads if thread cache is enabled).
  One possible scenario which exposed this problem was when thread which
  provided binlog dump to replication slave was implicitly/automatically
  killed when the same slave reconnected and started pulling data through
  different thread/connection.
  In 5.* versions memory hogging was added to CPU hogging. Moreover in
  those versions the problem also occured when one killed particular query
  in connection (using KILL QUERY) and later this connection had to wait for
  some table lock.
  
  This problem was caused by the fact that thread-specific mysys_var::abort
  variable, which indicates that waiting operations on mysys layer should
  be aborted (this includes waiting for table locks), was set by kill
  operation but was never reset back. So this value was "inherited" by the
  following statements or even other connections (which reused the same
  physical thread). Such discrepancy between this variable and THD::killed
  flag broke logic on SQL-layer and caused CPU and memory hogging.
  
  This patch tries to fix this problem by properly resetting this member.
  
  There is no test-case associated with this patch since it is hard to test
  for memory/CPU hogging conditions in our test-suite.

  sql/mysqld.cc@stripped, 2007-03-15 11:30:16+03:00, dlenev@stripped +6 -0
    We should not forget to reset THD::mysys_var::abort after kill operation
    if we are going to use thread to which this operation was applied for
    handling of other connections.

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	dlenev
# Host:	mockturtle.local
# Root:	/home/dlenev/src/mysql-4.1-bg25966

--- 1.627/sql/mysqld.cc	2007-03-15 11:30:21 +03:00
+++ 1.628/sql/mysqld.cc	2007-03-15 11:30:21 +03:00
@@ -1572,6 +1572,12 @@ void end_thread(THD *thd, bool put_in_ca
       thd=thread_cache.get();
       thd->real_id=pthread_self();
       (void) thd->store_globals();
+      /*
+        THD::mysys_var::abort is associated with physical thread rather
+        than with THD object. So we need to reset this flag before using
+        this thread for handling of new THD object/connection.
+      */
+      thd->mysys_var->abort= 0;
       thd->thr_create_time= time(NULL);
       threads.append(thd);
       pthread_mutex_unlock(&LOCK_thread_count);
Thread
bk commit into 4.1 tree (dlenev:1.2618) BUG#25966dlenev15 Mar