From: Date: November 15 2006 1:47pm
Subject: bk commit into 5.0 tree (svoj:1.2294) BUG#23526
List-Archive: http://lists.mysql.com/commits/15353
X-Bug: 23526
Message-Id: <20061115124742.6F3CAEA3@april.pils.ru>

Below is the list of changes that have just been committed into a local
5.0 repository of svoj. When svoj 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, 2006-11-15 16:47:34+04:00, svoj@stripped +1 -0
  BUG#23526 - show table status reports incorrect values for MyISAM tables
  
  This problem could happen when show table status get outdated copy
  of TABLE object from table cache.
  
  MyISAM updates state info when external_lock() method is called. Though
  I_S does not lock a table to avoid deadlocks. If I_S opens a table which
  is in a table cache it will likely get outdated state info copy.
  
  In this case shared state copy is more recent than local copy. This problem
  is fixed by reading state info directly from share not locking it.
  
  Affects MyISAM only. No good deterministic test case for this fix.

  myisam/mi_info.c@stripped, 2006-11-15 16:47:31+04:00, svoj@stripped +17 -8
    Since INFORMATION_SCHEMA does not lock a table, info->state can be
    far behind true values. For example if a table was taken from table
    cache. In this case we use share as state info source, as it is more
    recent than info->state.

# 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:	svoj
# Host:	april.(none)
# Root:	/home/svoj/devel/mysql/BUG23526/mysql-5.0-engines

--- 1.15/myisam/mi_info.c	2006-11-15 16:47:42 +04:00
+++ 1.16/myisam/mi_info.c	2006-11-15 16:47:42 +04:00
@@ -50,17 +50,26 @@ int mi_status(MI_INFO *info, register MI
   }
   if (flag & HA_STATUS_VARIABLE)
   {
-    x->records	 	= info->state->records;
-    x->deleted	 	= info->state->del;
-    x->delete_length	= info->state->empty;
-    x->data_file_length	=info->state->data_file_length;
-    x->index_file_length=info->state->key_file_length;
+    /*
+      Since INFORMATION_SCHEMA does not lock a table, info->state can be
+      far behind true values. For example if a table was taken from table
+      cache. In this case we use share as state info source, as it is more
+      recent than info->state.
+    */
+    MI_STATUS_INFO *state= (flag & HA_STATUS_NO_LOCK &&
+                            info->lock_type == F_UNLCK) ?
+                            &share->state.state : info->state;
+    x->records= state->records;
+    x->deleted= state->del;
+    x->delete_length= state->empty;
+    x->data_file_length= state->data_file_length;
+    x->index_file_length= state->key_file_length;
 
     x->keys	 	= share->state.header.keys;
     x->check_time	= share->state.check_time;
-    x->mean_reclength	= info->state->records ?
-      (ulong) ((info->state->data_file_length-info->state->empty)/
-	       info->state->records) : (ulong) share->min_pack_length;
+    x->mean_reclength= x->records ?
+                       (ulong) ((x->data_file_length - x->delete_length) /
+                       x->records) : (ulong) share->min_pack_length;
   }
   if (flag & HA_STATUS_ERRKEY)
   {