Fun with Bugs #15 - Recent News and Hawthorne Effect Studies

Let me present a quick review of new and recently verified MySQL bug reports (mostly in 5.6.12, but not only). Surely I have to start with this request that many my colleagues had already mentioned in their blogs:

Bug #69558 - Put *all* know bugs into the public bug tracking system at bugs.mysql.com. We may argue on how and when this should apply to "security" bugs, but automatic bi-directional replication (even if delayed) with Oracle internals bugs database is what I was also asking for since we were forced to use it. Click on "Affects Me" button there and let's hope that some day Oracle will publish list of bugs that affect most of community users and may even try to take this into account while making decisions.

I have good news for everybody who was following MySQL 5.6 Performance Schema overhead discussions. Bug #68413 is now "Verified". So it is officially confirmed now that there are use cases when performance overhead from Performance Schema being ON with default settings is at least 10%. We all knew that, and there was work in progress to reduce overhead for months already, but for some reason it took a long time and notable efforts from several people (starting with original bug reporter, surely) to get the bug formally "Verified" instead of being formally ignored.

Now, let me remind Oracle engineers about some bugs that probably are fixed already, but still are NOT "Closed" in our public bugs database:

• Bug #68022 - "DROP TABLE slow when it decompress compressed-only pages". As far as I understand it should be fixed in MySQL 5.5 at least, but it still hangs around "Verified".
• Bug #56332  - "Performance regression in DROP TABLE performance post 5.0.77". It is probably "Won't fix" for 5.0.x that is no longer supported, was fixed in 5.5 long time ago, and (check Bug #69316) should be finally fixed (again) in upcoming MySQL 5.6.13 and 5.7.2.

Unfortunately we still see regressions in new releases from Oracle. One that everybody who uses more than one datafile for shared InnoDB tablespace should know about is Bug #69623 - "since 5.5.32 & 5.6.12, innodb cant start with own multi-file tablespace". See Bug #69573 also. I already had to deal with customer affected (that upgraded to Oracle's 5.5.32), so the problem for production environments is real.

Bug #69653, "Use of uninitialized pthread_getspecific() key in debug builds", may sound unimportant to you, but it is yet another evidence that there are things to improve in code review and analysis in Oracle.

Good old Bug #62255 ("DROP USER can't drop users with legacy upper case host name anymore") had got yet another duplicate this week. Better just name your hosts all lowercase to avoid problems like this.

Should I even remind you that it hardly makes sense to use ORDER BY while defining views if you do not add LIMIT clause at the same time? If I should, please, check Bug #69678 - it shows that you may get hit of a regression bug in this case. One more change in behavior in 5.6.12 vs 5.5, but IMHO it's just easier to avoid this kind of views.

Now some "personal" things to mention. I keep wondering is there any work in progress on Bug #68487, "MDL hash can still be concurrency bottleneck"? I am also going to abuse this blog post to remind about and old documentation request I've made, Bug #68097. I had not double checked, but are we sure that all details on enabling PERFORMANCE_SCHEMA instruments are now properly documented? Hardly to assume this, as bug is still just "Verified". I also have one bug to add to the list of replication problems in 5.6.12, Bug #69574 - Slave crashes when applying row-based binlog entries in cascading replication...

Finally, some background theory. While trying to understand if my MySQL bugs-related activity can be useful at least theoretically I started to read about observer's paradox and ended up on a page describing Hawthorne effect:

"The Hawthorne effect is a form of reactivity whereby subjects improve or modify an aspect of their behavior being experimentally measured simply in response to the fact that they know they are being studied"

So, I do study community bugs processing in Oracle and describe my findings in public, and as a result engineers involved may start to improve bugs processing, no matter what I actually noted during my study or report in my Facebook and blog posts (that many consider annoying). Just because they know that they are being studied... Sounds like a plan! Stay tuned.