From: Date: March 13 2007 10:35pm
Subject: bk commit into 5.0 tree (dlenev:1.2479) BUG#25966
List-Archive: http://lists.mysql.com/commits/21850
X-Bug: 25966
Message-Id: <20070313213524.C06F5204132@mockturtle.local>

Below is the list of changes that have just been committed into a local
5.0 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-14 00:35:18+03:00, dlenev@stripped +3 -0
  Fix for bug #25966 "2MB per second endless memory consumption after LOCK
   TABLE ... WRITE".
  
  When thread which serviced some connection to which KILL command was applied
  (or its internal equivalent) was reused for servicing some other connection
  (via thread cache), this new connection started to hog CPU and memory once
  it had to wait for some table lock. 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. This problem also occured
  if one simply killed particular query instead of whole connection and when
  connection in which query was killed had to wait for some table lock.
  
  This problem was caused by the fact that THD::mysys_var::abort member, which
  is actually is not member of THD but is a sort of thread-specific variable 
  and 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). Indeed
  having this flag set without actual kill operation (and thus without setting
  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-14 00:35: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. 

  sql/sp_head.cc@stripped, 2007-03-14 00:35:16+03:00, dlenev@stripped +1 -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 further statements. 

  sql/sql_parse.cc@stripped, 2007-03-14 00:35:17+03:00, dlenev@stripped +3 -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 further statements.  

# 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-5.0-bg25966

--- 1.596/sql/mysqld.cc	2007-03-14 00:35:24 +03:00
+++ 1.597/sql/mysqld.cc	2007-03-14 00:35:24 +03:00
@@ -1681,6 +1681,12 @@ void end_thread(THD *thd, bool put_in_ca
       thd->real_id=pthread_self();
       thd->thread_stack= (char*) &thd;          // For store_globals
       (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);

--- 1.610/sql/sql_parse.cc	2007-03-14 00:35:24 +03:00
+++ 1.611/sql/sql_parse.cc	2007-03-14 00:35:24 +03:00
@@ -1604,7 +1604,10 @@ bool dispatch_command(enum enum_server_c
   DBUG_ENTER("dispatch_command");
 
   if (thd->killed == THD::KILL_QUERY || thd->killed == THD::KILL_BAD_DATA)
+  {
     thd->killed= THD::NOT_KILLED;
+    thd->mysys_var->abort= 0;
+  }
 
   thd->command=command;
   /*

--- 1.236/sql/sp_head.cc	2007-03-14 00:35:24 +03:00
+++ 1.237/sql/sp_head.cc	2007-03-14 00:35:24 +03:00
@@ -1087,6 +1087,7 @@ sp_head::execute(THD *thd)
 	ctx->enter_handler(hip);
         thd->clear_error();
 	thd->killed= THD::NOT_KILLED;
+        thd->mysys_var->abort= 0;
 	continue;
       }
     }