Description:
When testing a patch for valgrind warning when using bit type as primary key, myisam and
partitioning, I found a new bug:

In some cases a partitioned myisam primary key bit field is not found when queried. (it is
found in the correct partition in pruning, but when it tries to find the row, it gets the
wrong partition from the wrong value of the field somewere).

How to repeat:
create table t1 (a bit(27), primary key (a)) engine=myisam 
partition by hash (a)
(partition p0, partition p1, partition p2);
show create table t1;
insert into t1 values (1),(4),(7),(10),(13),(16),(19),(22),(25),(28),(31),(34);
select hex(a) from t1 where a = 7;
select a + 0 from t1 order by a;
explain partitions select a from t1 where a = 7;
drop table t1;

Think i found the problem, when 'uneven' bits are used, then the key_restore function
copies one byte too much in the memcpy back to the record.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/41867

ChangeSet@1.2518, 2008-02-07 15:09:59+01:00, mattiasj@witty.ndb.mysql.com +3 -0
  Bug#34358: Cannot find specified bit row in partitioned table
  
  Problem was incorrect data length in the key_restore function
  resulting in overwriting the search key.
  
  Solution, remove one byte in length if uneven bits are used.

Pushed into mysql-6.0-engines and mysql-5.1-engines

Pushed into 5.1.24-rc

Pushed into 6.0.5-alpha

Documented as follows in the 5.1.24 and 6.0.5 changelogs:

        In some cases, matching rows from a partitioned MyISAM
        using a BIT column as the primary key were not found by queries.

Also noted in the 5.1.23-ndb-6.3.11 changelog.