Fun with Bugs #21 - recently verified bugs in MySQL 5.6.13

Notable contribution of MySQL Community to MySQL 5.6.13 was explicitly recognized recently. But users and contributors still continue their efforts, as well as Oracle engineers. Even though MySQL 5.6.13 has been generally available just for few days, we already have several new bug reports and updates to known bugs at http://bugs.mysql.com. Let me present a short list with some comments.

• Bug #69915 is a great example of a "new thinking" inside Oracle. Todd Farmer does not only write about new ways to use PERFORMANCE_SCHEMA in MySQL 5.6 in his blog, but also reports bugs found in  the process to the public bugs database. This is what every responsible MySQL engineer in Oracle should do, if you ask me. Reporting bugs not related to customer confidential data or clear security issues to Oracle's internal bugs database only is a waste of additional time and efforts for all interested parties. This particular bug report is about statement/com/Query counter not incremented, but in this case I care more about the approach used (report bug in public) than the problem itself (even though it still shows that extra QA efforts are still needed for MySQL 5.6.x).
• Bug #69895 - "mysql 5.6.13 i386 ships with 64bit libraries" on Solaris. Not that many people still care about Solaris these days, but for Oracle as a vendor of both it would make sense to care more about proper packaging on this platform. It's also a regression bug that again questions even basic QA testing of the releases...
• Bug #69892 - "innodb stats interferes with innodb force recovery and drop/create tables". Shane is the most famous and productive bug reported over last 7 years, and he keeps up reporting bugs to public bug database. This one is serious enough, but I am more concerned about other recent bug report affecting MySQL 5.6.x that is still open: Bug #69907. It seems not only InnoDB statistics stored in tables, but also master and slave information stored in InnoDB tables may prevent any practical use of innodb_forced_recovery. This is pretty serious and now I wonder had anybody even tried to think about forced recovery while adding these new great features and more InnoDB tables to the "data dictionary"...
• Bug #69887 - EXPLAIN for UPDATE of a single row by PRIMARY KEY shows access type as "range". This may be not even new and is just weird, but 5.6.13 is still affected as it was recently verified:
  
  mysql> explain select * from tbl_sample where id = 1\G
  *************************** 1. row ***************************
             id: 1
    select_type: SIMPLE
          table: tbl_sample
           type: const
  possible_keys: PRIMARY
            key: PRIMARY
        key_len: 2
            ref: const
           rows: 1
          Extra: NULL
  1 row in set (0.00 sec)
  
  mysql> explain update tbl_sample set cnt = 1 where id = 1\G
  *************************** 1. row ***************************
             id: 1
    select_type: SIMPLE
          table: tbl_sample
           type: range
  possible_keys: PRIMARY
            key: PRIMARY
        key_len: 2
            ref: const
           rows: 1
          Extra: Using where
  1 row in set (0.01 sec)

Does this small list mean that there no more bugs in MySQL 5.6.13, but the ones above? No, many old bugs are still not fixed, some bugs were verified by Oracle engineers on 5.6.13 many days before the official release. You may get information about some of them by following links in my previous post.