My MySQL bugs 2013

I have been meaning to write down a list of issues I have bumped into with MySQL and any comments on them but until recently never actually did that. So now is time to start to write up some of the bugs or feature requests I have made so I can see how quickly they get resolved.  Many issues are “small” and if you use MySQL frequently they become a nuisance. Many of my feature requests are to make MySQL better and easier to use and I guess more professional and consistent. As more people use MySQL in larger installations these features become more important than they might have been on a single server, we can shut it down anytime type environment.  So here to start with are the bugs I have filed this year (2013) related to MySQL:

  • Bug#71219  – Please make skip_name_resolve a dynamic setting
  • Bug#71213 – MEM agent uninstall leaves the java directory there.
  • Bug#71212 – Modify the instance recognition behaviour to be managed “from the MEM server”
  • Bug#70784 – Adjust documentation and possibly defaults for sync_{master,relay_log}_info
  • Bug#70583 – INSERT ON DUPLICATE KEY UPDATE failing after MySQL 5.6 upgrade.
  • Bug#70213 – I_S.innodb_metrics does not collect all information by default which means it has to be configured manually. Grr.
  • Bug#70008 –  Please use the same option name in my.cnf and SHOW GLOBAL VARIABLES
  • Bug#69987 – Please do not provide different versions of tar balls with the same name…
  • Bug#69962 – Simplify the configuration files, reminds me of when I followed postfix more actively but a nice mechanism.
  • Bug#69948 – Avoid having to configure extra new parameters if not really needed (better defaults).
  • Bug#69845 – Provide an option to prevent creation of tables without a unique/PK
  • Bug#69809 – Tiny documentation bug.
  • Bug#69571 – I really think that MySQL should be stricter in a lot of things. Yet another example
  • Bug#65286 – not created by me but repartitioning is not optimised sometimes and probably should be
  • Bug#69564 – local changes should stay local. It would be nice to be able to write stuff to the binlog (for recovery) but not let the slave process this downstream. Running mysql_upgrade should behave the same too.  I don’t really understand why mysql_upgrade does not update the help tables.
  • Bug#69421 – some logging can be very verbose and it’s not rate-limited. That makes enabling the logging useless as it generates too much noise.
  • Bug#69360 – add counters to catch RBR configuration mistakes (PK updates/deletes changing more than one row)
  • Bug#69351 – logging inconsistency
  • Bug#69191 – replication configuration settings now shown
  • Bug#69158 – incomplete packaging
  • Bug#69102 – improve tracking of error situations
  • Bug#69099 – configuration inconsistencies
  • Bug#69098 – static configuration settings
  • Bug#69078 – incorrect/misleading warnings
  • Bug#68963 – statistics can tell you lies… (or need to be improved)
  • Bug#68863 – MySQL auto-warmup in 5.6 is good, but could be better
  • Bug#68834 – Store upgrade information inside the database
  • Bug#68639 – FLUSH TABLES FOR EXPORT was broken (fixed in 5.6.12)
  • Bug#68451 – Simplify configuration management: Provide more information on in I_S tables about the server itself such as whether variables are dynamically changeable and default settings.
  • Bug#68236 – more dynamic configuration requests
  • Bug#68171 – Documentation improvements (copying InnoDB tables), related to Bug#68639
  • Bug#68085 – Counters to catch issues
  • Bug#68012 – More dynamic configuration changes
  • Bug#31188 – Not my bug, but an important issue that it would be nice to get fixed
  • Bug#39274 – Or evaluating a function for each row rather than once

I’ll try and back fill this a bit as I get time and add new bugs / feature requests when I file them.

4 thoughts on “My MySQL bugs 2013”

  1. > So now is time to start to write up some of the bugs or feature requests I have made so I can see how quickly they get resolved.

    List can be convenient for tracking purpose and interesting for Community, but if you want some of bugs to be resolved quickly you need to open Support request and ask for it.

  2. Sveta, you should know. I spend a lot of time writing these _public_ reports but also creating the _same_ SR (private support request). That’s extremely frustrating as it wastes a lot of my time.

    Also many new MySQL releases mention fixes to bugs, referencing the internal system’s bug reference to which there is _no_ external reference. That’s not really very convenient.

    While I understand that some information may need to be filtered to not disseminate it publicly this splitting of bug/feature requests publicly or not means more work for everyone and less visibility to some issues.

  3. Simon, yes, I know. I also personally think having bug reports publicly available is very important.

    What I was going to say is our procedures of bug fix prioritization are getting improved for bugs, which customers escalate in their SRs. Of course, some bugs can not be fixed quickly, some can introduce new behavior in GA releases, others are feature requests. But explicitly asking to escalate bugs makes sense. At least you could get reasonable answer why it can not be fixed any time soon.

Leave a Reply