MySQL Bugs Verification - Is It Really Simple?

While it was explained already by Sveta and others what does it really mean to "Verify" (or "Confirm", in Launchpad/Percona's terms) a bug in MySQL software, and why this step in a bug's life cycle is important, we still often read complains about too much time taken to verify the bug even with a clearly repeatable test case that can be just copy/pasted, like Bug #69985 or notably more serious Bug #69990. Moreover, I often make comments of this kind myself...

So, it seems there is still a need for clear explanation of all steps that may be involved in verification of a MySQL or Percona Server (let's take server as a most complicated case) bug. First of all, both Oracle and Percona require engineers who process bugs to check them on latest releases and/or source code builds of all versions/branches that are currently GA and fully supported, and on all development versions. For Oracle MySQL bug it means check of recent builds from current source code of 5.1, 5.5, 5.6 and 5.7 and, for many kinds of bugs like packaging, also on official binaries of 5.1.71, 5.5.33, 5.6.13 and 5.7.1 provided by Oracle for the platform. Some bugs may be clearly OS-specific even based on description, but others may require checks on Linux, Windows or even Solaris and FreeBSD (if they are NOT repeatable on Linux). Note that there are also different kinds of Windows and different Linux distributions, both 32-bit and 64-bit, and sometimes all these details matter. So, if engineer did not bother to check everywhere before setting bug to "Verified", bug may come back to him with a request from development for some more checks...

On top of that from time to time MySQL developers and QA start to care about regression bugs more than usual and as a result ask engineers who process bugs to try to pinpoint the exact release when supposedly regression bug appeared. Sometimes it mean checks of 3 previous official releases, sometimes it means separate detailed study that only really brave people like Shane (who probably has all releases since 3.23.5x installed and ready to start anyway) do... Note that all these is for a bug with a clear test case, while many bug reports are not that obvious.

Surely, a lot of checks can be automated (as Sveta explained) using smart setups, MTR, MySQL sandboxes and some shell scripting. But then even a small bug/problem in scripting may lead to bugs NOT checked on some important version (like it happened with MySQL 5.6 at pre-GA stage just because it was no longer mysql-trunk, but mysql-5,6, while scripts remain the same). And then you know what happens - people like me note this problem and Pandora's box is opened...

On top of that, every "Verified" MySQL bug in Oracle should be copied to internal bugs database, and at this step one has to run a script (that may have bugs also) from a Web-form providing MySQL bug number, then check copied bug in the internal bugs database, set proper status for it, make sure it had got proper category (as not every category at http://bugs.mysql.com is supported in internal Oracle's bugs database), got proper priority and ends up assigned to the developer lead who can really care about it. Some bugs should obviously be immediately escalated, and there was a separate procedure for this... At least this was the case a year ago.

So, even if I was able sometimes to "Verify" a bug in a matter of 15 minutes since it was reported, proper verification even of a simplest server bug usually takes more than that, even if it was immediately noted by the engineer who had nothing more important to do at the moment. By the way, bugs processing is hardly a 24x7 service in any company, so we should NOT expect some engineer to really monitor all incoming bugs in a real time on Sunday.

Sounds like a really over-complicated procedure, isn't it? Is it any different in Percona? Yes, it's easier here as there is no need to copy from one bugs database to the other - everything is in one place. We also do not release binaries for Windows, FreeBSD or Solaris and thus usually do not care about bugs on these platforms much unless they are repeatable on Linux. But on the other hand Percona provides repositories of RPM and .deb packages, and thus some bugs had to be checked on all recent major releases of RHEL/CentOS, Debian and Ubuntu (that are officially fully supported platforms here). I also have to check on all major versions of Percona Server, 5.1, 5.5 and 5.6 at the moment. On top of that, if bug is not clearly related to Percona-specific feature, we have to check upstream MySQL version and, if it is affected, we have to report and link upstream bug to the Percona server bug. So, again, often we in Percona end up working with two bugs databases, a lot of copy/pasting and following other annoying procedures... So, do not expect Percona server bug to be "Confirmed" in a matter of minutes or days, even if it comes with a simple test case repeatable on a recent version. So it goes.

Summary is simple: please, respect hard and often boring work of engineers who process bugs and give them some time before complaining (this is a reminder for myself as well).

If you care a lot about the bug, probably you should just open a support request with a vendor (I hope you have a support subscription, if you really care that much?) and then use your power of a customer to make things happen. If it does not work this way - tell me and let me open Pandora's box (or can of worms, if you prefer) at Facebook...

Fun with Bugs #22 - Some Bug Reports You Should Not Miss

Yet another user installed MySQL 5.5.32 yesterday and got a system that can not start... It's really easy to help in this case - just downgrade back to 5.5.31 or upgrade to 5.5.33 if you can. Why problem happened during upgrade? Because of a regression bug #69623.

This case that was easily solved during a quick chat reminded me about the problem of bugs in production. Nobody expects any sane DBA to review every new bug report, but some of them should not be missed, at least when upgrading to any newer version. Regression bugs (I see 15 here reported for MySQL 5.6 GA versions and still "Verified", and it was a search for "regression" tag that may not be always used...) are in this category, same as bugs in new features that may be just enabled/always there by default. Let me list a few more for 5.6.13:

• Bug #69325 - "MySQL uses significantly more memory for ALTER TABLE than expected". Imagine you are trying to use more partitions than usual because MySQL 5.6 allows it, and plan to enjoy fast ALTER maybe while adding some indexes... just to end up swapping as crazy and everything hanging. Surprise...
• Imagine you use replication in MySQL 5.6, with status stored in tables:
  
  mysql> show variables like '%info%';
  +---------------------------+----------------+
  | Variable_name             | Value          |
  +---------------------------+----------------+
  | master_info_repository    | TABLE          |
  | relay_log_info_file       | relay-log.info |
  | relay_log_info_repository | TABLE          |
  | sync_master_info          | 10000          |
  | sync_relay_log_info       | 10000          |
  +---------------------------+----------------+
  5 rows in set (0.02 sec)
  and just run CHANGE MASTER from time to time (or some tool may do this even if you do not know about it) and restart your server. You know what? You may easily end up with:
  
• Bug #69825 - "InnoDB: Assertion failure in thread ... in file lock0wait.cc line 297", or
• Bug #69898 - "change_master() invokes ha_innobase::truncate() in a DML transaction" and same assertion as above actually, and then upon restart...
• Bug #69907 - "Error(1030): Got error -1 from storage engine" and no way to start up even with innodb_force_recovery maybe...

Why is that so? Probably at least partially because you blindly trusted Oracle MySQL 5.6 GA status and had not cared to monitor bug reports... I'll speculate about possible reasons in some other post.

Is there any way to prevent this kind of troubles? Nobody can guarantee bugs free releases for you, unfortunately, but monitoring bugs database for any new bugs or at least some other sources that do monitor bugs database, like this my blog or my Facebook page, give you notably more chances to prevent unexpected troubles. So, take care...

Fun with Bugs #21 - recently verified bugs in MySQL 5.6.13

Notable contribution of MySQL Community to MySQL 5.6.13 was explicitly recognized recently. But users and contributors still continue their efforts, as well as Oracle engineers. Even though MySQL 5.6.13 has been generally available just for few days, we already have several new bug reports and updates to known bugs at http://bugs.mysql.com. Let me present a short list with some comments.

• Bug #69915 is a great example of a "new thinking" inside Oracle. Todd Farmer does not only write about new ways to use PERFORMANCE_SCHEMA in MySQL 5.6 in his blog, but also reports bugs found in  the process to the public bugs database. This is what every responsible MySQL engineer in Oracle should do, if you ask me. Reporting bugs not related to customer confidential data or clear security issues to Oracle's internal bugs database only is a waste of additional time and efforts for all interested parties. This particular bug report is about statement/com/Query counter not incremented, but in this case I care more about the approach used (report bug in public) than the problem itself (even though it still shows that extra QA efforts are still needed for MySQL 5.6.x).
• Bug #69895 - "mysql 5.6.13 i386 ships with 64bit libraries" on Solaris. Not that many people still care about Solaris these days, but for Oracle as a vendor of both it would make sense to care more about proper packaging on this platform. It's also a regression bug that again questions even basic QA testing of the releases...
• Bug #69892 - "innodb stats interferes with innodb force recovery and drop/create tables". Shane is the most famous and productive bug reported over last 7 years, and he keeps up reporting bugs to public bug database. This one is serious enough, but I am more concerned about other recent bug report affecting MySQL 5.6.x that is still open: Bug #69907. It seems not only InnoDB statistics stored in tables, but also master and slave information stored in InnoDB tables may prevent any practical use of innodb_forced_recovery. This is pretty serious and now I wonder had anybody even tried to think about forced recovery while adding these new great features and more InnoDB tables to the "data dictionary"...
• Bug #69887 - EXPLAIN for UPDATE of a single row by PRIMARY KEY shows access type as "range". This may be not even new and is just weird, but 5.6.13 is still affected as it was recently verified:
  
  mysql> explain select * from tbl_sample where id = 1\G
  *************************** 1. row ***************************
             id: 1
    select_type: SIMPLE
          table: tbl_sample
           type: const
  possible_keys: PRIMARY
            key: PRIMARY
        key_len: 2
            ref: const
           rows: 1
          Extra: NULL
  1 row in set (0.00 sec)
  
  mysql> explain update tbl_sample set cnt = 1 where id = 1\G
  *************************** 1. row ***************************
             id: 1
    select_type: SIMPLE
          table: tbl_sample
           type: range
  possible_keys: PRIMARY
            key: PRIMARY
        key_len: 2
            ref: const
           rows: 1
          Extra: Using where
  1 row in set (0.01 sec)

Does this small list mean that there no more bugs in MySQL 5.6.13, but the ones above? No, many old bugs are still not fixed, some bugs were verified by Oracle engineers on 5.6.13 many days before the official release. You may get information about some of them by following links in my previous post.

Fun with Bugs #20 - welcome MySQL 5.6.13!

MySQL 5.6.13 is released today! Installation is in progress right now, so I had not checked anything yet personally in reality, but we have release notes to study.

I'll base my quick review on my older posts devoted to known bugs in MySQL 5.6.12 in three main areas: InnoDB, optimizer and replication. All quoted text below is taken from the release notes.

Let's start with InnoDB. From my "top 10" list I only see the following bug fixed in 5.6.13:

• Bug #69316. "Performance; InnoDB: A code regression introduced in MySQL 5.6 negatively impacted DROP TABLE and ALTER TABLE performance. This could cause a performance drop between MySQL Server 5.5.x and 5.6.x. (Bug #16864741, Bug #69316)"

Not much, really. But at least Bug #69623 is fixed (so you can use multi-file shared tablespace again) as expected and there are many other paragraphs in release notes speaking about InnoDB. Maybe it's only me having priorities not 100% corresponding to Oracle ones in this case.

Now, let's move to replication. From my "top 10" replication bugs in 5.6.12 I see the following fixed:

• Bug #69369. "Replication: The condition leading to the issue fixed in Bug #16579083 continued to raise an error even though the condition itself no longer cause the issue to occur. (Bug #16931177, Bug #69369)."
• Bug #69341 . "Replication: When rpl_semi_sync_master_timeout was set to an extremely large value, semi-synchronous replication became very slow, especially when many sessions were working in parallel. It was discovered that the code to calculate this timeout was inside the wait loop itself, with the result that an increase in the value of rpl_semi_sync_master_timeout caused repeated iterations. This fix improves the method used to calculate wakeup times, and moves it outside of the wait loop, so that it is executed one time only. (Bug #16878043, Bug #69341)"
• Bug #69096 - this actually fixed a minor remaining problem of referencing non-existent session variable, GTID_NEXT_LIST. The real problem was already fixed in 5.6.12 (see Bug #69045). 

That's all. But 2 serious bugs I cared about (among many others replication related fixes, I see 10 or so) is not bad.

Finally, regression bugs in optimizer. The following are fixed in 5.6.13:

• Bug #69471. "When selecting a union of an empty result set (created with WHERE 1=0 or WHERE FALSE) with a derived table, incorrect filtering was applied to the derived table. (Bug #69471, Bug #16961803)"
• Bug #69410. "For queries with ORDER BY ... LIMIT, the optimizer could choose a nonordering index for table access. (Bug #69410, Bug #16916596)"
• Bug #68897. "Some LEFT JOIN queries with GROUP BY could return incorrect results. (Bug #68897, Bug #16620047)".

3 out of 10 is good, but many optimizer regressions remain.

Installation finished, time for real life checks (and more posts based on results):

C:\Program Files\MySQL\MySQL Server 5.5\bin>mysql -uroot -proot -P3314 test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 9
Server version: 5.6.13 MySQL Community Server (GPL)

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

MySQL 5.6.13 looks promising enough from the first sight,and I surely hope new MySQL Cluster 7.3 release based on it (instead of a really much worse 5.6.11) is coming soon.

What is the problem with "To be fixed later" bug status?

Bug #69842 was actively discussed on Facebook recently. Mostly not it's technical content - people do agree that InnoDB probably needs separate doublewrite buffer(s) for every possible InnoDB page size. It's more about bugs processing approaches, so I have to say something about this.

The story was simple enough. I've mentioned this bug in my previous post and yesterday my dear friend Sinisa added some comments and set status to "To be fixed later". This had made bug reporter (who co-incidentally is a "small data engineer" at Facebook) unhappy, because (let me quote):

"...bugs can still be closed as "to be fixed later", which means even it may affect other users (it affect us, at least), nobody will see that as an open issue MySQL has - especially that some of us would like to be fixed sooner rather than later."

This story had got a happy end actually. James Day stepped in and set status "Verified" for this report as a feature request. But question remains: was setting status to "To be fixed later" a proper action in this case, what does this status mean and does it lead to any problems?

Note in any case that "To be fixed later" status had been used in public bugs database for 8+ years at least (for me it was just always there), this is NOT a recent evil Oracle invention. Let me quote my old post explaining both this and "Won't fix" status (also mentioned in that recent discussion):

• To be fixed later - it means that while the problem exists and verified, there is no way to fix it in current GA or development versions, or fix needs serious changes in software or data format, or serious development efforts and thus requires long term planning. Usually it means "To be fixed never".
• Won't fix - developers just do not want to fix this. This is more a "feature" than a "bug", even if user thinks differently. Users often ask for some things that, while make sense for them and their use case, may be against SQL standard or have acceptable workarounds in frames of current implementation etc.

As for problems, Domas later claimed that "To be fixed later" bugs are not visible in searches later. I'd say it depends on how you search. Click here to get the list of all (234 at the moment of writing) bugs having "To be fixed later" status. The status is "terminating" though, and thus the bug in this status is not visible when you search for "Active" bugs. Just try to search for "truncate" among active bugs using bugs database search, and you will NOT find Bug #68184, while the problem of TRUNCATE being surprisingly slow for InnoDB table when buffer pool is big (while DROP is fixed long time ago) is known and important to solve. On the other hand, simple Google search for site:bugs.mysql.com truncate slow shows this bug to me on the first page of results. Note that by default bugs database does NOT include feature requests (S4 bugs) into the search, so current status of bug report from Facebook may be not much better for searches actually.

So, depending on the way you search, having bug with status "To be fixed later" may be a problem (but only if you are not experienced in MySQL bugs search). Any other problems? One is mentioned in my quote above: I made a statement that "To be fixed later" used to mean "To be fixed never". Is this a true statement or a bad joke? Both, to some extent.

Let me explain this. Ideally status "To be fixed later" should be set (for a bug report or feature request that was originally "Verified"!) by a development manager or key developer (like Marko in case of InnoDB) who checked all planned bug fixes for current GA versions, all planned bug fixes and new features for the version currently in development and, based on available resources and priorities, made a decision (as this is his job) to NOT include the fix in any version that is currently under development. Ideally, at the same time, worklog is to be created for this feature and made public, so that people can contribute with ideas, questions and express their need for this new feature (or bug fix).

So, can we even suspect anything as ideal as above in case of bug #69842? Obviously we can not. Even if we assume that Sinisa has the power of making decisions on further InnoDB development, hardy he spent enough time on Monday to make sure this does NOT fit into InnoDB plans for MySQL 5.7 (that is still at very early stage of development. He had not referenced any worklog created (and this is not so easy if at all possible in Oracle it seems to create new public worklogs). Surely bug reporter have some reasons to think that in this case "To be fixed later" may be equal to "To be fixed never"... I may be wrong here, but then I am sure somebody will explain this in public and give some insights on the huge amount of work entire MySQL organization in Oracle did before he sent his comments :)

Another potential problem with "To be fixed later" bugs, even if they had got this status with good reasons and after following the ideal procedure described above, is the following: who and when reviews bugs in these status again? They should be reviewed at least when development of new version starts, that is, recently when work started on 5.7 all old "To be fixed later" bugs had to be reviewed and some of them had to get some comments and status "Verified" back, if they are now considered for a new feature, or status "To be fixed later" re-established for 2 more years (assuming new GA release every 2 years based on recent Oracle habits and statements). Please, check the list of "To be fixed later" bugs and try to find any evidence of something like this happened any time since 2011.

I know for sure only one iteration like this happened, and I made it myself back in 2007 or so maybe, probably even before MySQL AB joined Sun (some time before 5.1 GA). I worked with Trudy (and maybe Peter G.), main MySQL architects of that times, and was able to re-open some of "To be fixed later" bugs, not many. I am not sure if anybody tried to repeat this again, especially recently in Oracle. Let me stay corrected...

Fun with Bugs #19 - waiting for MySQL 5.6.13 and some real fun?

I feel like MySQL 5.6.12 was released ages ago, while in reality it was on June 3, less than 2 months ago. No wonder I feel so, after writing several posts about bugs fixed and not fixed in it... Anyway, we still have to wait for MySQL 5.6.13 for a week or even two probably and in the meantime I decided to write new post for this series based on good old idea of making a digest of my recent bugs-related posts at Facebook. I know, it's boring and annoying (same as waiting for the release of 5.6.13).

Let's start with Bug #69846 - "ICP does not work on UNIQUE indexes". Based on my quick tests presented there I'd say that ICP (index condition pushdown) actually does not work for InnoDB clustered key (being it explicit PRIMARY KEY or just the first UNIQUE KEY), and this is probably by design, as such index is "equal" to InnoDB table itself. I'd still prefer to see this explained in the manual. Bug is still "Open", so Oracle engineers may have different opinion.

Another bug made my day actually, it's Bug #69842 from Domas. It does not matter that it is "Open" or that doublewrite buffer does not work efficiently with InnoDB page sizes smaller than 16K... Question is how to create proper Latin-based term for writing something 3, 5 ("quintuple-writing") or 17 times...

Optimizer in MySQL had always been a source of endless fun. It seems that for some cases it worked properly last time in 5.1 (if not 5.0). Check Bug #69833 for a recent example, "Bad interaction between MIN/MAX and "HAVING SUM(DISTINCT)": wrong results". Yes, it's a weird corner case with not much real life use, but still it's a regression bug. In some areas MySQL 5.1 was better than any 5.5 or 5.6 GA version from Oracle so far :)

Bug #62578 is still affecting customers who use MySQL 5.5.x. Recent checks show that 5.6.12 is NOT affected (neither Sinisa nor me were able to repeat it on 5.6.12), but mysql client of 5.5.32 still crashes when you reside terminal (or putty) window it runs in. Fix is well know and probably found its way to 5.6 long time ago, but why it is NOT in 5.5? Yes, I still remember talks about a policy to fix bugs in older GA versions only when customers ask and there is no risk or high efforts involved, but isn't this the case for this bug?

I've spent a lot of time trying to find similar known bug report for Bug #69825 reported by my colleague, but failed. It seems new problem, at least in public bugs database. Sounds simple, "InnoDB: Assertion failure in thread ... in file lock0wait.cc line 297", affects 5.6.12 and the only repeatable test case so far is based on customer confidential data (as far as I know), but still... Why it is still "Open" and got no comments? Had everybody in Oracle decided that GTID-based crash safe replication with information stored in InnoDB tables in mysql database just always work, so it must be some bug reporter fault? It's not the case, dear colleagues, it's not the case...

Now something simple and easy to verify by code review, Bug #69827. "Hardcoded libdir in cmake", so that lib64 on Linux is used only for x86_64. Who cares I've asked? But even if we do not take 64-bit PowerPC into account any more, some sources claim 64-bit ARM-based servers are coming soon... Should be easy fix actually (hacked in by many users already probably).

If you are going to upgrade to MySQL 5.6 and had forgotten that configuration file in basedir (if present) overrides settings in /etc/my.cnf, check Bug #68643 - "sql_mode is unkind in my.cnf created by mysql_install_db". Yes, as it silently includes STRICT_TRANS_TABLES. It's just a feature request for now, so hardly is going to change any time soon (if at all). Just take care about this, I warned you.

 Week started with funny bugs mostly. This one is open for more than 7 years and still scare people, Bug #18256. If session is killed you still may see messages like this in your mysql command line client:

ERROR 1053 (08S01) at line 1: Server shutdown in progress

Do not panic, please. Server may be perfectly alive, just your session no longer works.

On the weekend I still had fun with the manual and friends who are scared by Oracle requests for personal information. Check Bug #69805 I've reported (or http://falseisnotnull.wordpress.com/2013/07/21/mysql-not-found-errors-precedence-docs-bug/ for the whole story) and note that fine manual does not describe what was really implemented correctly. Let them now decide who was wrong, manual (I hope) or implementation of the feature as designed. Error handling in stored routines is still to complex and far from perfect even in MySQL 5.6 if you ask me, at least comparing to good old Oracle PL/SQL (this is what I really miss since 2005 sometimes...)

That's all for now. I've spent this week digging around and trying to fix things and protect strangers from dangers like this:

Hope this helps somebody.

Fun with Bugs #18 - Feature Requests (Oldies but Goldies Part II)

In the previous "Fun with Bugs" posts I've mostly ignored feature requests. Users do file a lot of feature requests in MySQL bugs database, but until recently (when "Affects Me" button was introduced) there was no clear way to even try to influence the priority of the feature in development plans. There is still no way to see if the feature request has any priority. Surely, based on Oracle policies, nobody from Oracle will even try to give you a hint on when the "Verified" feature request is going to be implemented or what is its real internal priority...


Does it mean that there is no sense to make feature requests (or, for Oracle engineers, to process them and keep status in sync with reality)? No, it does not, IMHO. This is still one of few ways for a community user or even a customer to influence the future of MySQL. Even if Oracle will not start to act immediately in any obvious way based on your feature request, it will still be documented, reviewed by Oracle engineers, other community users and maybe even developers from other forks. Entire world will know what is missing (and accepted as missing by vendor, if feature request is "Verified"). Then, based on its status changes, entire world will know if anybody cares enough...




So, let me continue my previous post about oldest but still formally "Verified" bugs with a list of 12 oldest and still "Verified" feature requests:

1. Bug #400 is the oldest and it remains "Verified" since good old days when Monty himself replied to MySQL feature requests. It's about backslash (\) usage as escape character before single and double quotes. I do not have any opinion about it, but still it's the oldest still "Verified" feature request.
2. Bug #765 - "mysqlimport should read from stdin standard input". Maybe, it's a kind of a "Unix way" to have some option to do so...
3. Bug #1118  - "Allow multiple concurrent locks with GET_LOCK()". This one from Dean Ellis I'd like to see implemented years ago. And it was implemented recently by former famous MySQL developer, Konstantin Osipov, who had made a BSD-licensed patch available here. Feature request is still just "Verified", bit this is how it may work: even if not Oracle, somebody can pick up useful feature request and implement it.
4. Bug #1154 - "cannot rename temporary table". I really wonder why not to make RENAME working the same way as ALTER TABLE ... RENAME in this case. Nobody wants to touch old code and test cases maybe...
5. Bug #1207 - this is a request for function to count the number of substring occurrences in a string, like PHP's substr_count(). Workarounds are more or less obvious, so this feature request may hang around not implemented for 10 more years easily...
6. Bug #1214 - "Unique row identifier data type for MySQL (like MSSQL uniqueidentifier)". UUID() mostly works for this if MIXED/ROW-based replication is used, but still this concern expressed by James Day remains:
   
   

   "Decision needed for this bug is if UUID() should be our answer to a unique identifier feature request in 5.1 and later. It's very non-optimal for InnoDB primary key use because it puts the most rapidly changing parts of the time first."

   Check the bug report for different workarounds, but ultimate solution is not yet in place it seems.
7. Bug #1275 - "Multiple uninstall options if upgrade a preexisting install in same directory". This is a Windows-specific feature request and I am not sure what's going on now with new installers. I had never really tried to upgrade in place in real life using .msi or new installer (if maybe to verify some bug report). It's surely better to install every version into its own directory and then play with datadir in my.ini to make upgraded MySQL work with data from previous version.
8. Bug #1309 - "EXCEPT statement". One of the early requests to have all kind of relational operations requested by standard in MySQL. Of them we still have only UNION [ALL].
9. Bug #1310 - "optionally add queries with lock times to slow_query log". I assumed this is already implemented, but I may be wrong...
10. Bug #1327 - "I would like functions/SQL commands in the MySQL API/Language so that a client application can be notified when things happen in the database." Now I am not sure if we need to implement anything for this, but back in 2005 I thought there is something to consider here. Still "Verified" since that time.
11. Bug #1341 - "InnoDB ibdata1 never shrinks after data is removed". Still the case. Setting innodb_file_per_table=1 and using separate tablespaces for undo in MySQL 5.6 partially solves the problem (by removing reasons for ibdata1 to grow much). But users still complain, for 10 years already...
12. Bug #1343 - "index by date part of datetime field". I've suggested some kind of a workaround there back in 2005.

I think we had enough examples to understand that both reporting and reading feature requests is useful - you can get a workaround or even some kind soul providing a patch, even for the feature request that is still "Verified".