MySQL 5.6.12 is available to community for more than a week already, so people started to test and use it. And, no wonder, new bug reports started to appear. Let's concentrate on them in this issue.
I'd like to start with a funny one. Bug #69413 had scared some of my Facebook readers to death, as we see kernel mutex mentioned clearly in the release notes for 5.6.12. What, kernel mutex comes back again? No, it's just a result of null merge and, probably, copy/paste from the release notes for 5.5.32.
It seems recent bug reports for 5.6.12 are mostly related to small details that may not be of any importance to a typical user. For example, Bug #69419 that was reported by my colleague almost immediately after release questions the way mtr is used in the release process. Change related to fix for other bug had broken few tests, but tests were neither updated nor temporary disabled it seems. This is strange, at best, and can mean many things (from simple mistake to "nobody cares", to switch to some other tools for internal regression testing).
"Nobody cares" does NOT apply though, as during this week Shane Bester had reported 2 public bugs related to potential performance improvements possible in 5.6.12. Check Bug #69420 and Bug #69422. Looks like he tries to find and eliminate reasons for even less than smallest slowdown in benchmarks.
He is not the only one. Check Bug #69451. Event the smallest chunk of redundant code can not hide these days from careful users...
One topic for bug reports is ages old: MySQL still do not use proper data type for integers in many parts of the code. Bug #69431 from Shane is one of recent examples. Bug #69469 (that is more or less a duplicate of Bug #69249 reported for 5.6.11 a month ago), is another one, but related to a new feature introduced in 5.6. It seems that topic is valid for a new code as much as for older one that Monty and Sinisa were reviewing a decade ago. Let's hope that for MySQL 5.7 GA the review of the entire code base is planned, with the aim to find and fix all problems of this kind (among others).
Unfortunately it's not only about minor and cosmetic things. If you use raw devices with InnoDB and plan to upgrade to 5.6, check Bug #69424. It's not yet verified, and previous bug of this kind, Bug #68860, was set to "Not a bug" in two days... But, well, how one should upgrade with existing raw decide containing data, when code of srv_file_check_mode() function clearly says:
/*********************************************************************//**
Check if a file can be opened in read-write mode.
@return true if it doesn't exist or can be opened in rw mode. */
static
bool
srv_file_check_mode(
/*================*/
const char* name) /*!< in: filename to check */
{
os_file_stat_t stat;
memset(&stat, 0x0, sizeof(stat));
dberr_t err = os_file_get_status(name, &stat, true);
if (err == DB_FAIL) {
ib_logf(IB_LOG_LEVEL_ERROR,
"os_file_get_status() failed on '%s'. Can't determine "
"file permissions", name);
return(false);
} else if (err == DB_SUCCESS) {
/* Note: stat.rw_perm is only valid of files */
if (stat.type == OS_FILE_TYPE_FILE) {
if (!stat.rw_perm) {
ib_logf(IB_LOG_LEVEL_ERROR,
"%s can't be opened in %s mode",
name,
srv_read_only_mode
? "read" : "read-write");
return(false);
}
} else {
/* Not a regular file, bail out. */
ib_logf(IB_LOG_LEVEL_ERROR,
"'%s' not a regular file.", name);
return(false);
} } else {
/* This is OK. If the file create fails on RO media, there
is nothing we can do. */
ut_a(err == DB_NOT_FOUND);
}
return(true);
}
That is, if file is not a regular file we unconditionally return false, and as soon as this function returns false in all places it is used we just assume error. (I have to check this myself eventually as I have no raw decide at hand for immediate test, but code like this does not present in MySQL 5.5, so it seems good old manual page just can not be used any more.)
It seems Oracle MySQL engineers should pay more attention to testing upgrade procedures (and reading community bug reports). Even if eventually this may not be the case, currently community QA efforts (and public bugs database) are still important and sometimes lead to findings that seem new and unexpected to Oracle MySQL engineers.
Another serious enough bug from recently reported and verified, Bug #69444, is related to replication. It seems to be not really crash safe when DDL statement is involved. Potentially when crash happens during "wrong" time, DDL is going to be executed again upon slave restart.
That's all for now. MySQL 5.6.12 is going to be the best release ever for 6+ more weeks it seems, so we all have plenty of time to check it and contribute to public bugs database...
Saturday, June 15, 2013
Tuesday, June 4, 2013
Fun with Bugs #9 - MySQL 5.6.12, quick review
So, it seems we have MySQL 5.6.12 released officially. We have great Changes in MySQL 5.6.12 page already widely shared and people already blogging about a feature implemented by my dear friend Sinisa.
Quick scroll over changes shows 130+ bugs fixed and it will surely take time to understand the impact of all these fixes. We have 2 months for this till next release, so eventually we'll find out what's good in MySQL 5.6.12 and should we immediately switch to it from all other older 5.x.y versions.
But we have to start with something, and I'd like to start with bugs that I've mentioned in issue #7 and issue #6 of "Fun with Bugs" series here. Let's check them one by one, starting with older ones:
Bug #68299 - closed, fixed in 6.5.12
Bug #68251 (and Bug #68569) - closed, fixed in 5.6.12
Bug #68250 (semisync replication) - declared "Not a bug" for reasons I do not completely understand.
Bug #68220 (minor, when replication info is stored in tables) - still "Verified", but it's minor...
Bug #68192 (data types) - it was reported at 5.5.29 and 5.6.9 times and got no visible attention since verification. Nothing changed. This happens more often than I'd like to see with bug reports from Elena/MariaDB. I wonder why...
Bug #68171 (missing manual) - still no comments, since 5.6 RC times. Nothing changed.
Bug #68144 (custom character sets, regression) - no visible progress since 5.6 RC times. Nothing changed. Is this because SkySQL is now MariaDB? Who knows...
Bug #68097 (incomplete manual) - still "Verified". No changes. But this is a documentation request and from me, and I "like" SkySQL and MariaDB often enough at Facebook, so maybe logic is the same. Kidding...
Bug #68079 (lack of scalability for joins) - this my report was mentioned by DimitriK during the Conference and I am sure Oracle is working on it, but public bugs database shows nothing new.
Bug #68041 (zero date, regression) - from Elena. Still no comments
Bug #67982 (partitioning) - from Elena. Still no comments, since last year
Bug #68350 - closed, fixed in 5.6.12!
Bug #68525 - replication bug verified since February 28. No visible progress.
Bug #69005 - regression bug in optimizer. Still "Verified" since April 19.
Now, more recently reported or updated:
Bug #69095 - replication fails with GTID enabled and master changes from SBR to RBR. Now back to "Open", but Giuseppe proved it is repeatable (his way, using MySQL Sandbox) even with 5.6.12. So, just some time wasted.
Bug #69135 - mysql.slave_master_info is not updated. Still "Verified", but not so much time passed since May 6, so let's hope for 5.6.13 to fix it.
Bug #69236 - still "Open". But it seems Mark Callaghan is sure that Oracle works on single-thread performance issues he reported, so we can stop caring much about this and just wait for outcomes...
Bug #68354 - the last but not the least, my favorite Federated storage engine keeps providing interesting ways to crash server. Bug was reported for 5.6.10 and is still "Verified".
That is, of 18 bugs I "cared about" for whatever reasons as of 5.6.11 only 3 or 4 were fixed in 5.6.12. Let's hope you are more lucky.
In any case, 5.6.12 looks like a good step forward, with many serious bugs fixed. I see only 17 bugs explicitly mentioned as affecting 5.6.12 here, and none of them looks like a recent regression (correct me if I am wrong). So, MySQL 5.6 is moving into the right direction, no matter what I write or do.
Quick scroll over changes shows 130+ bugs fixed and it will surely take time to understand the impact of all these fixes. We have 2 months for this till next release, so eventually we'll find out what's good in MySQL 5.6.12 and should we immediately switch to it from all other older 5.x.y versions.
But we have to start with something, and I'd like to start with bugs that I've mentioned in issue #7 and issue #6 of "Fun with Bugs" series here. Let's check them one by one, starting with older ones:
Bug #68299 - closed, fixed in 6.5.12
Bug #68251 (and Bug #68569) - closed, fixed in 5.6.12
Bug #68250 (semisync replication) - declared "Not a bug" for reasons I do not completely understand.
Bug #68220 (minor, when replication info is stored in tables) - still "Verified", but it's minor...
Bug #68192 (data types) - it was reported at 5.5.29 and 5.6.9 times and got no visible attention since verification. Nothing changed. This happens more often than I'd like to see with bug reports from Elena/MariaDB. I wonder why...
Bug #68171 (missing manual) - still no comments, since 5.6 RC times. Nothing changed.
Bug #68144 (custom character sets, regression) - no visible progress since 5.6 RC times. Nothing changed. Is this because SkySQL is now MariaDB? Who knows...
Bug #68097 (incomplete manual) - still "Verified". No changes. But this is a documentation request and from me, and I "like" SkySQL and MariaDB often enough at Facebook, so maybe logic is the same. Kidding...
Bug #68079 (lack of scalability for joins) - this my report was mentioned by DimitriK during the Conference and I am sure Oracle is working on it, but public bugs database shows nothing new.
Bug #68041 (zero date, regression) - from Elena. Still no comments
Bug #67982 (partitioning) - from Elena. Still no comments, since last year
Bug #68350 - closed, fixed in 5.6.12!
Bug #68525 - replication bug verified since February 28. No visible progress.
Bug #69005 - regression bug in optimizer. Still "Verified" since April 19.
Now, more recently reported or updated:
Bug #69095 - replication fails with GTID enabled and master changes from SBR to RBR. Now back to "Open", but Giuseppe proved it is repeatable (his way, using MySQL Sandbox) even with 5.6.12. So, just some time wasted.
Bug #69135 - mysql.slave_master_info is not updated. Still "Verified", but not so much time passed since May 6, so let's hope for 5.6.13 to fix it.
Bug #69236 - still "Open". But it seems Mark Callaghan is sure that Oracle works on single-thread performance issues he reported, so we can stop caring much about this and just wait for outcomes...
Bug #68354 - the last but not the least, my favorite Federated storage engine keeps providing interesting ways to crash server. Bug was reported for 5.6.10 and is still "Verified".
That is, of 18 bugs I "cared about" for whatever reasons as of 5.6.11 only 3 or 4 were fixed in 5.6.12. Let's hope you are more lucky.
In any case, 5.6.12 looks like a good step forward, with many serious bugs fixed. I see only 17 bugs explicitly mentioned as affecting 5.6.12 here, and none of them looks like a recent regression (correct me if I am wrong). So, MySQL 5.6 is moving into the right direction, no matter what I write or do.
MySQL 5.6 Experiences - .mylogin.cnf and mysql_config_editor
Having basic ideas of how I am going to describe new features explained, I can proceed with some real (and I hope useful) content. As I read this page about new features from top to bottom, let's start with security improvements...
(!?) http://serge.frezefond.com/2013/02/mysql-5-6-credentials-securely-stored/ - some explanations on what this new feature is about and, most importantly, code of the mysql_showconfigpwd.cc program from Serge to expose the credentials stored
(!?) http://mysqldump.azundris.com/archives/104-.mylogin.cnf-password-recovery.html - Kristian explains file format and provides PHP code to expose the credentials stored
(?#) http://www.skysql.com/blogs/kolbe/mysql-56-security-through-complacency - Kolbe explains (among other rambling on MySQL 5.6 security features) how to "hack" the mask_password_and_print() function from
Bug #68680 - manual had some wrong details on where the .mylogin.cnf file is located on Windows, now fixed
Bug #68034 - while it is declared a "Duplicate", in the bug report you can read how this feature can be used to workaround Bug #66546 that nobody is going to fix (see Todd’s comment)
Bug #68277 - build problem affecting mysql_config_editor, fixed in 5.6.11
Bug #66546 - some people are not happy that there is no way to hardcode password in the script,
without getting warning. But who cares? Only Todd, who explained how to use one new security improvement to workaround problem created by another security improvement...
If you have any new links or bug reports related to the topic of this post, please, send them in comments.
At the same time, this new feature probably caused additional work for developers and QA of MySQL Connectors and Workbench (as I have reasons to think it was probably decided that this time, for 5.6 GA, connectors and tools should really support all new GA features at the moment of GA release). I had found only one related bug in the public bugs database to prove this point (Bug #68356 - problems in Workbench tests that cover both MySQL 5.5 and 5.6), but who knows how many of them were reported internally and then fixed...
I share concerns that this feature may cause wrong feeling of improved security, that's why I talked about it during my presentation and had written this post. I agree with the following comment to Kolbe's post from Sergei Golubchik though:
.mylogin.cnf and mysql_config_editor
Details:
- you can store authentication
credentials encrypted in an option file named .mylogin.cnf (in user's home directory or in
%APPDATA%\MySQL on Windows) - password is no longer stored in plain text (like in .my.cnf) and still is not exposed in the command lines...
- you have to use mysql_config_editor utility to create the .mylogin.cnf file
- but if someone can read .mylogin.cnf, they have your MySQL password
- ~/.mylogin.cnf is not a more secure place to store your password than ~/.my.cnf
Links:
(!) http://mysqlblog.fivefarmers.com/2012/08/16/understanding-mysql_config_editors-security-aspects/ - Todd explains that "ease of use" was the goal of this feature, not actually security(!?) http://serge.frezefond.com/2013/02/mysql-5-6-credentials-securely-stored/ - some explanations on what this new feature is about and, most importantly, code of the mysql_showconfigpwd.cc program from Serge to expose the credentials stored
(!?) http://mysqldump.azundris.com/archives/104-.mylogin.cnf-password-recovery.html - Kristian explains file format and provides PHP code to expose the credentials stored
(?#) http://www.skysql.com/blogs/kolbe/mysql-56-security-through-complacency - Kolbe explains (among other rambling on MySQL 5.6 security features) how to "hack" the mask_password_and_print() function from
client/mysql_config_editor.cc file in the source code to build mysql_config_editor version that will show stored password in plain text. Bug #68602 mentioned in this post is not related to this file and tool (but related to security, still "Verified" as of today and will be discussed later in this series). Bugs:
New MySQL features always come with related bugs. This simple enough tool and new file caused several related reports:Bug #68680 - manual had some wrong details on where the .mylogin.cnf file is located on Windows, now fixed
Bug #68034 - while it is declared a "Duplicate", in the bug report you can read how this feature can be used to workaround Bug #66546 that nobody is going to fix (see Todd’s comment)
Bug #68277 - build problem affecting mysql_config_editor, fixed in 5.6.11
Bug #66546 - some people are not happy that there is no way to hardcode password in the script,
without getting warning. But who cares? Only Todd, who explained how to use one new security improvement to workaround problem created by another security improvement...
If you have any new links or bug reports related to the topic of this post, please, send them in comments.
Summary
While some more secure approach to store and provide authentication credentials for scripts was requested many times and by many users, I am not sure this new feature adds anything to security. IMHO it just may simplify work for a lazy DBA who does not remember proper permissions for .my.cnf file...At the same time, this new feature probably caused additional work for developers and QA of MySQL Connectors and Workbench (as I have reasons to think it was probably decided that this time, for 5.6 GA, connectors and tools should really support all new GA features at the moment of GA release). I had found only one related bug in the public bugs database to prove this point (Bug #68356 - problems in Workbench tests that cover both MySQL 5.5 and 5.6), but who knows how many of them were reported internally and then fixed...
I share concerns that this feature may cause wrong feeling of improved security, that's why I talked about it during my presentation and had written this post. I agree with the following comment to Kolbe's post from Sergei Golubchik though:
"There's not much one can do to improve password handling. The mysql client needs to store some bit of information somewhere that allows to identify a user to the server. So if a bad guy would have access to this bit of information - no matter how obfuscated or encrypted it is - he will be able to impersonate the user just as well by repeating whatever mysql client does."
Sunday, June 2, 2013
Fun with Bugs #8 - what's wrong with Oracle's way of handling public MySQL bugs database
Many people seem unhappy with the way Oracle develops MySQL. I am not one of them. I think very few really important things are missing and in this post I'd like to concentrate on one of them: having internal and public bugs databases not in sync in too many cases.
Let me quote myself to explain where problem starts:
Anything wrong with this? I am not sure it's totally wrong in general. There should be some reason for you to become Oracle customer, and having access to more information may be a good enough reason (having a way to request and even demand fixes you need is even better reason). But I think this is wrong if in the corresponding bug in the internal Oracle database there is public comment explaining current status of the bug.
This leads to my point: public bug reports are usually NOT in sync with corresponding internal bug reports.
Status may be not in sync and useful public (and not any confidential or security-related) comments in the internal bugs database are not accessible to the community until some kind soul in Oracle closes the public bug and documents the fix. We know from some examples that this may not happen for months after the bug is really closed. Public bug may be declared a "Duplicate" of something that we know nothing about, check Bug #65326 (here I've got no hints after public request unfortunately), and so on.
How this can be solved (assuming Oracle is going to solve this and still plan to rely on public bugs database and community QA efforts - who knows if they really want these and for how long)? I see two options:
If nothing like this (investment of time or costs from Oracle side to increase value of public bugs database, to put it simple) happens any time soon it will be a clear indication (for me alt least) of decreasing interest in community bug reports and QA efforts in general. Small step to the direction I personally do not like.
Let me quote myself to explain where problem starts:
"Now the most important thing you should know about MySQL bugs processing the way it is done now in Oracle. When bug is "Verified" and(!) considered serious enough, it is copied to the Oracle internal bugs database and further processing, including status changes etc, is done there. All further comments to the public bug report are then copied to internal bug report automatically, but no comments or status changes in internal bug report are copied to public bug in any other way but by explicit action of some Oracle engineer."Why is this a problem? Check Bug #42415 for example. It had a lot of activity and even patches pushed until December, 2010, but it is still "Verified". The problem is real and there is even a workaround implemented for cases like this in Percona Server. On October 2012 Sherii asked for status update:
"It says a patch has been committed, but the "status" is "patch pending". Was this actually put in a version of MySQL? If so, which version?
I am interested in this fix, and put in my "vote" to get this fixed."
Then bug became just "Verified" and we know it is not fixed. But why, what prevents this or when it will be fixed? Nobody knows. Well, I have a hint based on a comment from former colleague upon explicit request... But what if you are NOT hanging around on my Facebook page on a regular basis and you are NOT an Oracle customer? You may have to just wait fishing in the dark or keep asking in public (or investing time into workarounds for this problem in your software, or keep telling others that Oracle "kills" MySQL and creating foundations to "save" it, up to you to decide).Anything wrong with this? I am not sure it's totally wrong in general. There should be some reason for you to become Oracle customer, and having access to more information may be a good enough reason (having a way to request and even demand fixes you need is even better reason). But I think this is wrong if in the corresponding bug in the internal Oracle database there is public comment explaining current status of the bug.
This leads to my point: public bug reports are usually NOT in sync with corresponding internal bug reports.
Status may be not in sync and useful public (and not any confidential or security-related) comments in the internal bugs database are not accessible to the community until some kind soul in Oracle closes the public bug and documents the fix. We know from some examples that this may not happen for months after the bug is really closed. Public bug may be declared a "Duplicate" of something that we know nothing about, check Bug #65326 (here I've got no hints after public request unfortunately), and so on.
How this can be solved (assuming Oracle is going to solve this and still plan to rely on public bugs database and community QA efforts - who knows if they really want these and for how long)? I see two options:
- Automatically copy back (with a delay, with some manual approval work if needed) all public comments and status changes from internal bug to corresponding public bug report. Technically this is probably easy and there should be scripts almost ready (as forwarding from public bugs database is automated by scripts). Exceptions like security bugs are easy to identify. Delayed replication should help to prevent mistakes. I asked for this more than once when I still worked in Oracle...
- Manually copy back all essential comments and status changes. This is probably a full time job for an engineer or technical writer (or maybe even several), or member of Bugs Verification team, or some independent contractors with non-disclosure agreement signed and trainings passed. I'd happily participate in this kind of activity as an independent contractor in my free time and, I hope, Percona would not be against this.
If nothing like this (investment of time or costs from Oracle side to increase value of public bugs database, to put it simple) happens any time soon it will be a clear indication (for me alt least) of decreasing interest in community bug reports and QA efforts in general. Small step to the direction I personally do not like.
Sunday, May 26, 2013
Fun with bugs #7, still mostly about 5.6.11
It looks like now Oracle will release new 5.6.x every 2 months, so while I'd happily write about bugs fixed in 5.6.12 we still have to wait for the official release to happen. I am too impatient to wait for 5.6.12, so let me write this post of a classical kind - just a summary of my MySQL bugs' related posts on Facebook since the previous one.
I have to start with replication-related bugs in 5.6.11 pointed out by Giuseppe Maxia:
While searching for something else, I've noted Bug #60101 in "Patch pending" status for more than 2 years. As usual, I've complained in public and got this bug... "Closed" with a comment saying nothing about specific versions where the fix first appeared. Well done, Sinisa, really, but this bug report is still a yet another example showing that Oracle does NOT always care to keep public bugs database in sync with real development and follow their own procedures of bugs processing. Unfortunately...
And now back to performance that 5.6.x is all about. Mark Callaghan had not only reported in public about his findings on singe-thread performance of 5.6.11 (in Bug #69236), but later had provided a detailed enough analysis showing that it's not only a client or UTF-8 related problem, but something else as well... Still the bug is "Open" since May 15. I had written about it at least 3 times, but it seems this does not help any more to get anybody's attention. I wonder should I become more annoying blogger again and publish new "Fun with Bugs" issue every week.
Obviously I was so impressed by "300 man-years of QA experience" Oracle now invests into MySQL (statement from famous keynote session Tomas Ulin gave during PLMCE 2013) that now I pay extra attention to every bug report that points out some problem with tests that QA engineers are supposed to run. Here are the recent examples:
Bug #69252 - All the parts.partition_max* tests are broken with MTR --parallel. If nobody ever tried to run these tests with --parallel (as it seems), then we can safely assume that nobody cared to run them at all in production, as "--parallel" feature was added (long time ago) to make test runs faster in production environment...
Bug #69265 - -DBUILD_CONFIG=mysql_release -DWITH_DEBUG=ON fails 4 and skips 27 MTR tests. Similar situation - if nobody runs tests on debug builds on a regular basis (as it seems), what QA is really doing instead? This bug report is still "Open".
One may say that all these problems are known internally and are in the internal bugs database (reported long time ago), but I have no way to verify this kind of statement, so feel free to ignore it if it ever made. Make your own conclusions, but personally I do not understand how or why quality may increase without regular testing. Fortunately, many community members had NOT given up yet and continue to report bugs and test failures - this gives me some more hope to see MySQL 5.6 as the "best release ever" one day.
On a positive side, InnoDB team rocks as usual when they see useful bug report. Check Bug #69276 - it was accepted and verified by developers in a matter of hours.
Surely there are things to note in older MySQL server versions as well. Recently my Bug #67259 had got more evidence from my colleague (as customers continue to hit it or something similar to it), so note that the problem is still repeatable on Oracle's MySQL 5.5.31 as well.
I'd like to end this post with a word of warning about Federated storage engine. It is still able to provoke crashes, like in Bug #68354, and users hit these crashes in production. Unfortunately Oracle is hardly going to fix any bug in this storage engine (or any other storage engine but InnoDB actually), so here MariaDB may be our only hope. Others would just happily remove it once and forever, while I am not sure there are good alternatives for all use cases it covers...
That's all for now. I skipped "funny" reports, "not a bugs" and hot discussions not really interesting to anybody but participants this time. Let's hope next release of "Fun with Bugs" will be about great fixes in MySQL 5.6.12.
I have to start with replication-related bugs in 5.6.11 pointed out by Giuseppe Maxia:
- Bug #69095 - replication fails with GTID enabled and master changes from SBR to RBR. This bug is "Verified" since April 30, but got no public comments since that.
- Bug #69135 - mysql.slave_master_info is not updated. This serious bug is verified since May 6, but, again, got no visible attention since that.
While searching for something else, I've noted Bug #60101 in "Patch pending" status for more than 2 years. As usual, I've complained in public and got this bug... "Closed" with a comment saying nothing about specific versions where the fix first appeared. Well done, Sinisa, really, but this bug report is still a yet another example showing that Oracle does NOT always care to keep public bugs database in sync with real development and follow their own procedures of bugs processing. Unfortunately...
And now back to performance that 5.6.x is all about. Mark Callaghan had not only reported in public about his findings on singe-thread performance of 5.6.11 (in Bug #69236), but later had provided a detailed enough analysis showing that it's not only a client or UTF-8 related problem, but something else as well... Still the bug is "Open" since May 15. I had written about it at least 3 times, but it seems this does not help any more to get anybody's attention. I wonder should I become more annoying blogger again and publish new "Fun with Bugs" issue every week.
Obviously I was so impressed by "300 man-years of QA experience" Oracle now invests into MySQL (statement from famous keynote session Tomas Ulin gave during PLMCE 2013) that now I pay extra attention to every bug report that points out some problem with tests that QA engineers are supposed to run. Here are the recent examples:
Bug #69252 - All the parts.partition_max* tests are broken with MTR --parallel. If nobody ever tried to run these tests with --parallel (as it seems), then we can safely assume that nobody cared to run them at all in production, as "--parallel" feature was added (long time ago) to make test runs faster in production environment...
Bug #69265 - -DBUILD_CONFIG=mysql_release -DWITH_DEBUG=ON fails 4 and skips 27 MTR tests. Similar situation - if nobody runs tests on debug builds on a regular basis (as it seems), what QA is really doing instead? This bug report is still "Open".
One may say that all these problems are known internally and are in the internal bugs database (reported long time ago), but I have no way to verify this kind of statement, so feel free to ignore it if it ever made. Make your own conclusions, but personally I do not understand how or why quality may increase without regular testing. Fortunately, many community members had NOT given up yet and continue to report bugs and test failures - this gives me some more hope to see MySQL 5.6 as the "best release ever" one day.
On a positive side, InnoDB team rocks as usual when they see useful bug report. Check Bug #69276 - it was accepted and verified by developers in a matter of hours.
Surely there are things to note in older MySQL server versions as well. Recently my Bug #67259 had got more evidence from my colleague (as customers continue to hit it or something similar to it), so note that the problem is still repeatable on Oracle's MySQL 5.5.31 as well.
I'd like to end this post with a word of warning about Federated storage engine. It is still able to provoke crashes, like in Bug #68354, and users hit these crashes in production. Unfortunately Oracle is hardly going to fix any bug in this storage engine (or any other storage engine but InnoDB actually), so here MariaDB may be our only hope. Others would just happily remove it once and forever, while I am not sure there are good alternatives for all use cases it covers...
That's all for now. I skipped "funny" reports, "not a bugs" and hot discussions not really interesting to anybody but participants this time. Let's hope next release of "Fun with Bugs" will be about great fixes in MySQL 5.6.12.
Monday, May 20, 2013
More details on "MySQL 5.6 Experiences" coming soon...
I've already shared my presentation few hours before I made it during PLMCE 2013, back on April 24. The idea behind the presentation was simple (and I think that any MySQL user who is planning to upgrade to MySQL 5.6.x in production should do something like this): let's read the "What Is New in MySQL 5.6" manual page and check new features one by one.
This is what I am going to do with the content of that manual page in the upcoming blog posts (and what was done as background work for the presentation):
During the upcoming weeks I plan to explain every slide in more details (as 50 minutes were not enough for this) here, grouping them by topics (security improvements, InnoDB improvements etc) and check status of all the active bugs mentioned in it (it makes even more sense now, when 5.6.12 is released). I'll also check and comment on new bugs for each major feature mentioned (if any).
The goal of this upcoming series of posts ("MySQL 5.6 Experiences") is to give enough information and references for any interested MySQL user to be able to decide if any of new features are important and mature enough to be used in production and, thus, does it really make sense to upgrade to MySQL 5.6 right now. I do not want to just share optimistic "the best release ever" or pessimistic "buggy and not mature to be used in production" statements - I want to provide some background.
This is what I am going to do with the content of that manual page in the upcoming blog posts (and what was done as background work for the presentation):
- Remove extra details and add references to each major feature
- For every feature description add extra references (articles about the feature, bugs related to the feature).
- Add some comments based on personal experience (if any)
During the upcoming weeks I plan to explain every slide in more details (as 50 minutes were not enough for this) here, grouping them by topics (security improvements, InnoDB improvements etc) and check status of all the active bugs mentioned in it (it makes even more sense now, when 5.6.12 is released). I'll also check and comment on new bugs for each major feature mentioned (if any).
The goal of this upcoming series of posts ("MySQL 5.6 Experiences") is to give enough information and references for any interested MySQL user to be able to decide if any of new features are important and mature enough to be used in production and, thus, does it really make sense to upgrade to MySQL 5.6 right now. I do not want to just share optimistic "the best release ever" or pessimistic "buggy and not mature to be used in production" statements - I want to provide some background.
Saturday, April 20, 2013
Fun with Bugs #6 - MySQL 5.6.11
Last time I had written about bugs here it was a beginning of February, and hardly somebody could imagine that we were going to have 2 more months of winter, 2 more months to wait for next MySQL 5.6 GA release or that in 2 months and two weeks I'll be speaking about MySQL in public for 50 minutes based on my own presentation, and speaking about bugs (surely)...
In any case, MySQL 5.6.11 looks promising and had got a lot of bugs fixes (check at least this nice post by Todd Farmer). Time for me to get back to bugs I've mentioned in the previous "Fun with Bugs" issue and then check for some new ones already reported in 5.6.11.
So, from that list (that I've actually sent to customers first weeks after MySQL 5.6 GA more than once), we still have the following bugs NOT fixed in 5.6.11 it seems:
- Bug #68299 (EXPLAIN output for UPDATE/DELETE can still be wrong)
- Bug #68251 (semisync replication) - that's sad, actually...
- Bug #68250 (semisync replication) - this is now in "No feedback" status, and it's strange as, even if reporter does not reply to further comments or questions, it was repeated by Oracle engineers. Maybe patch is not ready to use, but the bug is real.
- Bug #68220 (minor, when replication info is stored in tables)
- Bug #68192 (data types) - it was reported at 5.5.29 and 5.6.9 times and got no visible attention since verification
- Bug #68171 (missing manual) - still no comments, since 5.6 RC times
- Bug #68144 (custom character sets, regression) - no visible progress since 5.6 RC times
- Bug #68097 (incomplete manual) - here we've got a blog post on the topic at least, and even a definitive guide from Domas, but not sure if manual itself had improved. Still "Verified".
- Bug #68079 (scalability for joins) - this my report had not got any visible attention since February 1. Not a big deal, 5.6 still a bit better than 5.5 in that case, but it seems I'll have to ask DimitriK about it in person during the Conference
- Bug #68041 (zero date, regression) - still no comments
- Bug #67982 (partitioning) - still no comments, since last year
So, 11 out of 20 bugs from my original list are still there, in 5.6.11, even though several of them were reported by one of top Community bug reporters before GA announcement.
Now, let's check some recent serious bugs affecting 5.6.11:
Bug #68350 - optimizer bug with a simple test case from Shane (since February 16) that is still repeatable in 5.6.11
Bug #68525 - replication bug verified since February 28
Bug #69005 - regression bug in optimizer
As a result, I'd say that 5.6.11 is surely better than 5.6.10 (nobody should continue using that version now it seems), but 5.6 GA still has a long way ahead before all claims about the best version ever become definitely true. It seems that it is still a lot of work to do on replication, optimizer and even InnoDB bug fixing (to say nothing about the manual).
In any case, MySQL 5.6.11 looks promising and had got a lot of bugs fixes (check at least this nice post by Todd Farmer). Time for me to get back to bugs I've mentioned in the previous "Fun with Bugs" issue and then check for some new ones already reported in 5.6.11.
So, from that list (that I've actually sent to customers first weeks after MySQL 5.6 GA more than once), we still have the following bugs NOT fixed in 5.6.11 it seems:
- Bug #68299 (EXPLAIN output for UPDATE/DELETE can still be wrong)
- Bug #68251 (semisync replication) - that's sad, actually...
- Bug #68250 (semisync replication) - this is now in "No feedback" status, and it's strange as, even if reporter does not reply to further comments or questions, it was repeated by Oracle engineers. Maybe patch is not ready to use, but the bug is real.
- Bug #68220 (minor, when replication info is stored in tables)
- Bug #68192 (data types) - it was reported at 5.5.29 and 5.6.9 times and got no visible attention since verification
- Bug #68171 (missing manual) - still no comments, since 5.6 RC times
- Bug #68144 (custom character sets, regression) - no visible progress since 5.6 RC times
- Bug #68097 (incomplete manual) - here we've got a blog post on the topic at least, and even a definitive guide from Domas, but not sure if manual itself had improved. Still "Verified".
- Bug #68079 (scalability for joins) - this my report had not got any visible attention since February 1. Not a big deal, 5.6 still a bit better than 5.5 in that case, but it seems I'll have to ask DimitriK about it in person during the Conference
- Bug #68041 (zero date, regression) - still no comments
- Bug #67982 (partitioning) - still no comments, since last year
So, 11 out of 20 bugs from my original list are still there, in 5.6.11, even though several of them were reported by one of top Community bug reporters before GA announcement.
Now, let's check some recent serious bugs affecting 5.6.11:
Bug #68350 - optimizer bug with a simple test case from Shane (since February 16) that is still repeatable in 5.6.11
Bug #68525 - replication bug verified since February 28
Bug #69005 - regression bug in optimizer
As a result, I'd say that 5.6.11 is surely better than 5.6.10 (nobody should continue using that version now it seems), but 5.6 GA still has a long way ahead before all claims about the best version ever become definitely true. It seems that it is still a lot of work to do on replication, optimizer and even InnoDB bug fixing (to say nothing about the manual).
Subscribe to:
Posts (Atom)