5.1 doesn't solve all merge table hell from 5.0.

This week I've had to revisit merge tables once again due to customers experiencing problems. Although 5.1 merge table implementation is a huge improvement over 5.0, there still remains some critical bugs.

My list is still growing:

bug #45800: crash when replacing into a merge table and there is a duplicate
bug #45781: infinite hang/crash in "opening tables" after handler tries to open merge table
bug #45796: invalid memory reads and writes when altering merge and base tables
bug #45777: check table doesn't show all problems for merge table compliance in 5.1

Not to mention a few feature requests, and even documentation clarification for some manual sections.

some useful additions to query generator

I've been on vacation this week, and decided to fine-tune some old QA code. Opened the manual to see the syntax for a select statement, and afterwards added to my random select generator the following:

• all index hints (force, use, ignore, for join, for order by, for group by)
• lock in share mode, for update
• key_block_size for individual indexes
• hash, btree, rtree for individual indexes
• unique, fulltext, spatial for indexes

Especially important is the 'lock in share mode' addition. The reason is InnoDB
has many serious bugs with this locking mode (insert ... select, and others) in read committed mode.

So, I don't need multitable delete or update to reproduce those bugs, since I can just do a simple select locking in share mode. For example, the following bugs previously went without proper testcase until I discovered this:

assert btr/btr0pcur.c line 217 -innodb_locks_unsafe_for_binlog or read committed
5.1.35 crashes with Failing assertion: index->type & DICT_CLUSTERED
Strange error messages about locks from InnoDB

some bug stats

So I did some checking at the number of bugs I've reported since start of 2005. Seems I'm at the top of my game here!

• P1 Server bugs: 180 (next runner up PeterG with 127)
• P1 + P2 Server bugs: 321 (next runner up PeterG with 311)

Interesting to note that most of my bug filing happened after 2006, but I started working at MySQL in 2005, so that's why I've used that start date.

The runner ups mostly report bugs in alpha versions, falcon, maria, and beta versions of mysql.
Nearly all of my bugs are in the current GA versions since that is what most of our customers use.

On occasion I go off on a tangent and try break the subquery optimizations in 6.0, but this
is only a small percentage of the total.