This week we had finally got MySQL 5.6.10 released as GA. It's a big deal, first MySQL GA release with the entire development process happened in Oracle from day one, quantum leap (as every second blog post says these days) in many areas, from scalability to replication performance, with InnoDB fulltext indexes and PERFORMANCE_SCHEMA improvements in between... So, this week it makes sense to concentrate on 5.6 GA and nothing else.
As one of my former colleagues noted, no GA is bug free. Surely there are known and verified bugs in 5.6.10, but not that many. Let me just give you a list to check, in case you plan to upgrade/switch to 5.6 in production:
- Bug #68300 (crash when password expire is set for a user, in a corner case)
- Bug #68299 (EXPLAIN output for UPDATE/DELETE can still be wrong)
- Bug #68277 (problem to build with system zlib)
- Bug #68251 (semisync replication)
- Bug #68250 (semisync replication)
- Bug #68220 (minor, when replication info is stored in tables)
- Bug #68192 (data types)
- Bug #68171 (missing manual)
- Bug #68165 (upgrade)
- Bug #68164 (minor, replication from older versions)
- Bug #68163 (minor, upgrade)
- Bug #68144 (custom charsets, regression)
- Bug #68118 (installing)
- Bug #68107 (client crash, ujis charset)
- Bug #68097 (incomplete manual)
- Bug #68079 (scalability for joins)
- Bug #68041 (zero date, regression)
- Bug #68040 (zero date, InnoDB)
- Bug #68019 (table lost during ALTER)
- Bug #67982 (partitioning)
These were mostly new bug reports, since December 27, 2012. Some older reports may also still be valid, but not many. I've carefully checked the last list of bugs "that would be nice to fix
in MySQL 5.6 before GA" that I'd created while still working in Oracle,
dated August 26, 2012. Of the bugs listed there only Bug #64683 is still "Verified" (I had not checked if it is repeatable). The rest were closed mostly at RC stage or even before 5.6.8.
I keep monitoring number of open bug reports that require processing, and this week it was around 320, below the level of August, 2012, even though inflow increased a bit since 5.6 GA announcement, as community users started to check 5.6 more actively.
Does this mean that Oracle does a good job and we should not care much about bugs processing now? Not 100% sure yet.
Some bug reports about the new features started to appear soon after GA announcement and still need Oracle attention. Check Bug #68281, for example, before relying on multi-threaded slave as a solution to all your replication performance problems. Users claim they get wrong results from 5.6.10, see Bug #68001, but nobody cares to reply. Business as usual :)
Anyway, I plan to check how bugs processing works without external influence via Facebook. That's why I stop regular posting about MySQL server bugs until official 5.6.11 release. Let's see what happen if I leave Oracle alone for some time.
I still can't figure out why my mysqlbinlog bug I filed was fixed in 5.7 and not 5.6. Sigh.
ReplyDeleteDo you mean this one, http://bugs.mysql.com/bug.php?id=65812? Yes, I see no good reasons to NOT fix it in 5.5 and 5.6.
ReplyDeleteI'd say that it does not make sense to even close bug fixed only in 5.7 now, when there were no public release of 5.7 and its code is not accessible. Public bug can equally well remain "Verified" - nobody in community can see or check the fix anyway.
Unless it was backported and nobody mentioned anything, I expect it won't be fixed until 5.7. There is no reason it should not have been done in 5.5 at least, which was GA when I created the bug.
ReplyDeleteWe can easily check if it was backported...
ReplyDeleteAs for reasons, let me try to explain you Oracle GA bugfixing policy as of August, 2012 (surely it could change after that). There is a limited number of bugs in all(!) GA versions that are fixed per year. These bugs are taken from the list ordered by some internal priority calculated based on some complex formula. This list is composed of bugs escalated (explicitly) by Oracle customers via support requests. There are small chances for bugs without associated support requests to be added/merged to this list, but only once in 3 months and only if somebody from MySQL Support cares to add them explicitly.
Developers are free to fix any other bugs (not from this list) as well in GA, but they need explicit permission from MySQL Support to include the fix into GA. Moreover, the procedure described above (ordering bug fixes and giving priorities to bugs escalated by customers) is applied because a) bug fixing resources for GA verions are limited, key developers need time to work on new versions, and b) bug fixes cause regressions sometimes, so the fewer changes in GA the safer it is for users :)
Security bugs are considered and fixed separately, surely.
Based on the above, your bug was probably never escalated by any customer, or it was, but has low enough internal priority and has to wait and/or nobody of developers and MySQL Support engineers noted it and cared enough to escalate it in time or just fix and ask to include this fix into GA. Nothing personal.
Having this procedure in mind I started this blog and posts on Facebook, to inform both customers and Oracle engineers about some bugs that may require escalation, in case they missed it. Customers then may escalate bug reports I've mentioned explicitly and Oracle engineers just get yet another reminder...