Saturday, December 9, 2017

Fun with Bugs #58 - Bug of the Day From @mysqlbugs

In 2013 I had a habit of writing about MySQL bugs on Facebook almost every day. Typical post looked like this one, link to the bug and few words of wondering with a bit of sarcasm.
By the way, check last comments in Bug #68892 mentioned there - the problem of LOST_EVENTS in master's binary log and a way to workaround it still valid as of MySQL 5.7.17.
At that time I often got private messages from colleagues that Facebook is a wrong media for this kind of posts, these posts make MySQL look "buggy" etc, and eventually I was shut up (for a year or so) in a more or less official way by combined efforts of my employer at that time and Oracle MySQL officials.

A year later I started to write about MySQL bugs again on Facebook, but these posts were not regular any more, and maybe became a bit less sarcastic. Years later, I agree that Facebook should better be used for sharing photos of cats, or nice places, or family members, or even for hot political discussions, as these things annoy people much less than MySQL bugs. So, the need for different media for short annoying messages about MySQL bugs is clear to me. I do think the right media is Twitter (it is annoying by itself), and I am present there as @mysqlbugs since December 2012 actually. I am not a big fan of it historically and used to open it mostly to share information about yet another my blog post, but recently (after they allowed to write longer messages there) I decided to pay more attention to it (until its gone entirely and replaced by something else). So, I post a link to one MySQL bug there every day for a week or so, with the #bugoftheday tag. I quickly noticed that the tag was used by others to share photos of nice insects/bugs, but I don't mind for my posts to end up among those, and I am ready to share some of my related photos as well.

To summarize, I am going to write short messages about MySQL bugs regularly on Twitter. I try to write about some bug I recently notices just because it is new, improperly handled or was involved in some customer issue that I worked on. Let me share 5 last bugs mentioned there, so you can decide if it makes sense for you to follow me or #bugoftheday:
  • Bug #88827 - "innodb uses too much space in the PK for concurrent inserts into the same table". Interesting finding by Mark Callaghan during his recent benchmarking efforts. Still "Open".
  • Bug #88788 - "log_bin is not considered correctly an makes binary logging unusable!". This report by Oli Sennhauser (quickly declared a duplicate of my older Bug #75507) got a really nice number, and it's also interesting how efforts to name hosts in a nicely structured manner may play against poor DBA...
  • Bug #88776 - "Issues found by PVS-Studio static analyzer". Related post with the detailed analysis of problems found by the tool was mentioned few days ago by somebody from MariaDB on Slack, so I immediately noted that the bug comes from the same author, Sergey Vasiliev.
  • Bug #88765 - "This bug reporting form has a ridiculously short character limit for the bug syn". The bug report about MySQL bugs database itself. I also hit the limit there way more often than I'd like to. Discussion continues, but I feel that this is not going to be fixed...
  • Bug #87526 - "The output of 'XA recover convert xid' is not useful". One of our customers hit this problem recently. I can only agree with Sveta Smirnova here, "Output of XA RECOVER should show ID which can be used in XA COMMIT statement."
So, if the list above seems useful or interesting, please, follow me on Twitter. Let's continue to have regular fun with MySQL bugs, now using (hopefully) a more appropriate media!

As a side note, if you are interested in older bugs opened this day years ago and still "Verified", please, check this great page by Hartmut! You may find really great reports like Bug #79581- "Error 1064 on selects from Information Schema if routine name has '\0'", by Sveta Smirnova. This bug is 2 years old today...

6 comments:

  1. Were more bugs opened from possible problems reported in https://medium.com/@CPP_Coder/code-quality-comparison-of-firebird-mysql-and-postgresql-53e39fc3298d

    ReplyDelete
    Replies
    1. I noted only https://bugs.mysql.com/bug.php?id=88776 so far, while that post mentions many more cases found by the PVS-Studio

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. I am wondering what is the reason you do not post bugs from MariaDB (your current employer)

    ReplyDelete
    Replies
    1. The reason is simple: I do not discuss bugs in software of my current employee in the blog.

      When I worked in Oracle this blog (and Facebook and Twitter accounts) had not existed, the first post here was a week or so before I quit from Oracle. When I worked in Percona I had not discussed Percona bugs much, and now I rarely mention MariaDB bugs (even though Google search for "MDEV" in my blog give me 20 hits, so in 20 posts I did mentioned some MariaDB bug in some context).

      I have other means/media to discuss bugs of current employee. I processed bugs at bugs.mysql.com while working in Oracle, and you can find many my public comments and my bug reports there. I processed bugs for different Percona projects while working there, and you can find both my public comments and bug reports at https://bugs.launchpad.net/percona-server etc. Now in MariaDB I am not formally involved in public bugs processing, but I do report bugs in public in MariaDB, MaxScale and ColumnStore. You can find my bug reports at jira.mariadb.org.

      Bugs in software I have to support as a part of my job are not for public fun (I have enough of it in internal discussions), most of the time. So, I have fun with bugs in upstream MySQL and, rarely, Percona software.

      Delete
    2. You are not alone. I rant about many things but not about my employer.

      Delete