From: Date: October 6 2006 12:17pm
Subject: bk commit into 4.1 tree (svoj:1.2556) BUG#22937
List-Archive: http://lists.mysql.com/commits/13232
X-Bug: 22937
Message-Id: <20061006101746.01908E6E@april.pils.ru>

Below is the list of changes that have just been committed into a local
4.1 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-10-06 15:17:42+05:00, svoj@stripped +1 -0
  BUG#22937 - Valgrind failure in 'merge' test (ha_myisammrg.cc:329)
  
  This is addition to fix for bug21617. Valgrind reports an error when
  opening merge table that has underlying tables with less indexes than
  in a merge table itself.
  
  Copy at most min(file->keys, table->key_parts) elements from rec_per_key array.
  This fixes problems when merge table and subtables have different number of keys.

  sql/ha_myisammrg.cc@stripped, 2006-10-06 15:17:41+05:00, svoj@stripped +14 -1
    Copy at most min(file->keys, table->key_parts) elements from rec_per_key array.
    This fixes problems when merge table and subtables have different number of keys.

# 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/BUG22937/mysql-4.1-engines

--- 1.62/sql/ha_myisammrg.cc	2006-10-06 15:17:45 +05:00
+++ 1.63/sql/ha_myisammrg.cc	2006-10-06 15:17:45 +05:00
@@ -249,9 +249,22 @@ void ha_myisammrg::info(uint flag)
   if (flag & HA_STATUS_CONST)
   {
     if (table->key_parts && info.rec_per_key)
+    {
+#ifdef HAVE_purify
+      /*
+        valgrind may be unhappy about it, because optimizer may access values
+        between file->keys and table->key_parts, that will be uninitialized.
+        It's safe though, because even if opimizer will decide to use a key
+        with such a number, it'll be an error later anyway.
+      */
+      bzero((char*) table->key_info[0].rec_per_key,
+            sizeof(table->key_info[0].rec_per_key) * table->key_parts);
+#endif
       memcpy((char*) table->key_info[0].rec_per_key,
 	     (char*) info.rec_per_key,
-	     sizeof(table->key_info[0].rec_per_key)*table->key_parts);
+             sizeof(table->key_info[0].rec_per_key) *
+             min(file->keys, table->key_parts));
+    }
   }
 }