Recent couple of days our team was pointed to number of bugs in MySQL 5.0 which again seriously shakes the confidence in both MySQL Quality Control and bug fix promptness.

Let me just take couple of bugs as examples:

Triggers broken with auto-increment columns for Innodb tables (bug 26316). As you can see this bug is reported in February – over 6 months ago and it is still in verified state even though it has “serious” severity.

ORDER By DESC broken for Innodb tables (bug 31001) This is also very interesting – the VERY basic functionality gets broken and passes quality control. And why it is broken ? Because minor optimization was implemented in MySQL 5.0.



Surely Baron is right Bug fixes are not much different from new features in terms of possibility of breaking things.

These raise few questions in my head:

What is MySQL Current Bug Policy ? A long time ago MySQL had Monty’s bug policy of “no known bugs in release” when it was changed to “no known serous bugs in release” and I think later it died off completely, at least in practice.

As you can see now serious bugs can remain unfixed for over half a year. Furthermore there is no good errata documentation which would outline which things have known problems which MySQL can’t fix fast.

What is the state of MySQL Quality Assurance I would tell both bugs are very basic but especially second one.

So how it happened so it was not caught ? I believe the problem is serious lack of concurrent stress testing and the fact MySQL Test Suite does way too many tests only for MyISAM storage engine which well allows bugs like this to slip through.

What can we learn from this ?

I think we should continue to be cautions using new features which first came in MySQL 5.0 They are now much better than were when MySQL 5.0 just came out (aka minefield) but still they are not at quality levels of base MySQL features.

Plus we should be careful and not to take minor upgrades lightly – this is one of many things which was broken along the way in MySQL 5.0 release so being careful is the best.

It also may be good idea to sample queries from your application together with sample database and package it as a test suite to ensure queries which you’re using will not break. You would not catch trigger bug this way but it can be helpful for basic query bugs at least. Plus it is not that hard to do.