bk commit into 5.1 tree (kroki:1.2408)

[kroki]

Below is the list of changes that have just been committed into a local
5.1 repository of tomash. When tomash 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-01-25 20:04:57+03:00, kroki@stripped +1 -0
  Merge moonlight.home:/home/tomash/src/mysql_ab/mysql-5.0-bug23527
  into  moonlight.home:/home/tomash/src/mysql_ab/mysql-5.1-bug23527
  MERGE: 1.1810.2510.1

  sql/sql_cache.cc@stripped, 2007-01-25 20:04:52+03:00, kroki@stripped +0 -0
    Auto merged
    MERGE: 1.76.8.1

# 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:	kroki
# Host:	moonlight.home
# Root:	/home/tomash/src/mysql_ab/mysql-5.1-bug23527/RESYNC

--- 1.103/sql/sql_cache.cc	2007-01-25 20:05:06 +03:00
+++ 1.104/sql/sql_cache.cc	2007-01-25 20:05:06 +03:00
@@ -1761,8 +1761,18 @@ void Query_cache::free_cache()
 {
   DBUG_ENTER("Query_cache::free_cache");
   if (query_cache_size > 0)
-  {
     flush_cache();
+  /*
+    There may be two free_cache() calls in progress, because we
+    release 'structure_guard_mutex' in flush_cache().  When the second
+    flush_cache() wakes up from the wait on 'COND_flush_finished', the
+    first call to free_cache() has done its job.  So we have to test
+    'query_cache_size > 0' the second time to see if the cache wasn't
+    reset by other thread, or if it was reset and was re-enabled then.
+    If the cache was reset, then we have nothing to do here.
+  */
+  if (query_cache_size > 0)
+  {
 #ifndef DBUG_OFF
     if (bins[0].free_blocks == 0)
     {
@@ -1804,6 +1814,12 @@ void Query_cache::free_cache()
     flush_in_progress flag and releases the lock, so other threads may
     proceed skipping the cache as if it is disabled.  Concurrent
     flushes are performed in turn.
+
+    After flush_cache() call, the cache is flushed, all the freed
+    memory is accumulated in bin[0], and the 'structure_guard_mutex'
+    is locked.  However, since we could release the mutex during
+    execution, the rest of the cache state could have been changed,
+    and should not be relied on.
 */
 
 void Query_cache::flush_cache()