Fun with Bugs, Issue #4, January 2013

This post will cover bugs I've "escalated" on Facebook during the period from January 28 till January 31. There were several serious bug reports noted, but many were taken from this great page that was created by Hartmut and updates every day. I had to find new source of fun, as Oracle reduced number of open and unassigned server bugs even more and processes new ones really fast this week. So, let's speak about some "Oldies but Goldies"...

I'd like to start with Bug #39489 ("In progress" for 2 years) from one of my former bosses, Dean. I've noted recently that I still can see private comments made by me in older  reports, so I know that I asked to fix this in 5.5, even if after GA. Discussion that happened after my post about this bug confirmed bug status, so we will hardly see this fixed in 5.6 (that was about replication improvements among other things). I understand that adding runtime checks may be a complex task, but it is still sad that limitation of initial 5.0 design is not really removed even in 5.6.

While Oracle now processes "Open" server bug reports fast enough to keep with the inflow and even clean up the backlog of 2012, bugs processing does NOT stop at verification stage or after creating some patch. Some older bug reports look forgotten, like Bug #59844. What should users think when bug is "Patch pending" for 2 years? I think that bug status was not updated when the bug was closed in internal bugs database. But maybe it is still not fixed. Should I do a cluster code review to find out? I can.

Bug #64181 was reported by Facebook, Oracle customer probably, a year ago, but is still work in progress according to my good old friend Sinisa. Strange to see it NOT fixed before 5.6 GA that is about InnoDB improvements even more than new replication features. Let's hope fix for this is a part of something great Oracle prepares for us all and we will be positively surprised by how great 5.6 will work on SSDs.

Another bug that had not got any visible attention after verification on the first 5.5 GA release is Bug #59858. 2 years passed since cmake-based build system is used for recent MySQL version, but one should still assume that there is no way to build static binaries out of the box. I don;'t care much, but then maybe just "Won't fix"? This is at least fair.

I understand that if bug is "Verified" for years, this is probably because nobody really cares about the problem from users side. But I do not believe that, say, wrong metadata issues like Bug #42490 are so irrelevant for developers of connectors, for example. Still, the bug is just "Verified" for 4 years, and probably dozens of lines of code are added to every second MySQL connector on the planet to take this special case into account.

It is even more strange to see bug just "Verified" for years, like Bug #64164 when other forks/clones/derivatives of MySQL include the fix (Drizzle in this case). That's probably because Oracle developers are NOT allowed to even read the code from other vendors unless there is an OCA signed. Or for some other reason? We can only guess and be happy that Oracle is not the only vendor of MySQL software these days.

In some cases, when real fix is hard or not on top of priorities, having current limitations of design and implementation properly documented in the manual would be just enough, to not have wrong assumptions at least. Bug #54194 is one of these cases. But is is just "Verified" for 2.5 years.

Let's move on to recent reports though. I see that Bug #68222 is still just "Open" and probably had not got any attention from any Oracle engineers, even though it is for commercial MEB software and is about inability to make backups without assertion failure. Does not look good to me, but maybe all engineers who could check it are on their way to FOSDEM... I hope this is the only reason.

By the way, when manual describes limitations of current MySQL server, it would be nice to be correct and do not limit users from trying smart solutions that work, in case of ALTER TABLE, for example. Check my Bug #68223 to find out that you can actually mix changes of partitioning scheme with many other changes in table structure in single ALTER TABLE statement. For tables 500G+ in size this may save you some time.

I was somewhat offended by the fact that Bug #68184 (that is making TRUNCATE TABLE for InnoDB tables just useless if you have big buffer pool) was set to "To be fixed later" by my dear friend Sinisa eventually, but if does NOT mean "To be fixed never" - let it be so. I hope Facebook engineers with either fix this themselves, or ask Percona to fix it, or force Oracle to care.

Those who plan to switch to MySQL 5.6 soon, should be really careful while using new features. Some of them (like password logging changes, see Bug #68200) still do not work the way they are advertised in the manual and numerous blog posts on how great MySQL 5.6 is going to be.

At the beginning of this week I was still able to "verify" some bugs faster than Oracle engineers, see Bug #68192 as an example. Later during the week I've noted that new bug reports are processed fast enough. Hence this shift in attention towards old and probably forgotten bug reports. Maybe eventually this series will be just closed. But this depends mostly on Oracle's attitude and approaches to bugs processing and bug fixing more than on anything else. I see positive changes, let's just check if they are permanent.

I still plan to have special issues about Cluster and Workbench bug reports. I'd also like to write about famous bug reporters, with some statistics to share. So, to be continued, this is not the end, yet...