This post is an update to the status of various MySQL bugs (some with patches) that I’ve filed over the past couple of years (or that people around me have). I’m not looking at POWER specific ones, as there are these too, but each of these bugs here deal with general correctness of the code base.

Firstly, let’s look at some points I’ve raised:

• Incorrect locking for global_query_id (bug #72544)
  Raised on May 5th, 2014 on the internals list. As of today, no action (apart from Dimitri verifying the bug back in May 2014). There continues to be locking that perhaps only works by accident around query IDs.Soon, this bug will be two years old.
• Endian code based on CPU type rather than endian define (bug #72715)
  About six-hundred and fifty days ago I filed this bug – back in May 2014, which probably has a relatively trivial fix of using the correct #ifdef of BIG_ENDIAN/LITTLE_ENDIAN rather than doing specific behavior based on #ifdef __i386__
  What’s worse is that this looks like somebody being clever for a compiler in the 1990s, which unlikely ends up with the most optimal code today.
• mysql-test-run.pl –valgrind-all does not run all binaries under valgrind (bug #74830)
  Yeah, this should be a trivial fix, but nothing has happened since November 2014.
  I’m unlikely to go provide a patch simply because it seems to take sooooo damn long to get anything merged.
• MySQL 5.1 doesn’t build with Bison 3.0 (bug #77529)
  Probably of little consequence, unless you’re trying to build MySQL 5.1 on a linux distro released in the last couple of years. Fixed in Maria for a long time now.

Trivial patches:

• Incorrect function name in DBUG_ENTER (bug #78133)
  Pull request number 25 on github – a trivial patch that is obviously correct, simply correcting some debug only string.
  So far, over 191 days with no action. If you can’t get trivial and obvious patches merged in about 2/3rds of a year, you’re not going to grow contributions. Nearly everybody coming to a project starts out with trivial patches, and if a long time contributor who will complain loudly on the internet (like I am here) if his trivial patches aren’t merged can’t get it in, what chance on earth does a newcomer have?
  In case you’re wondering, this is the patch:

  --- a/sql/rpl_rli_pdb.cc
  +++ b/sql/rpl_rli_pdb.cc
  @@ -470,7 +470,7 @@ bool Slave_worker::read_info(Rpl_info_handler *from)
   
   bool Slave_worker::write_info(Rpl_info_handler *to)
   {
  -  DBUG_ENTER("Master_info::write_info");
  +  DBUG_ENTER("Slave_worker::write_info");

• InnoDB table flags in bitfield is non-optimal (bug #74831)
  With a patch since I filed this back in November 2014, it’s managed to sit idle long enough for GCC 4.8 to practically disappear from anywhere I care about, and 4.9 makes better optimization decisions. There are other reasons why C bitfields are an awful idea too.

Actually complex issues:

• InnoDB mutex spin loop is missing GCC barrier (bug #72755)
  Again, another bug filed back in May 2014, where InnoDB is doing a rather weird trick to attempt to get the compiler to not optimize away a spinloop. There’s a known good way of doing this, it’s called a compiler barrier. I’ve had a patch for nearly two years, not merged :(
• buf_block_align relies on random timeouts, volatile rather than memory barriers (bug #74775)
  This bug was first filed in November 2014 and deals with a couple of incorrect assumptions about memory ordering and what volatile means.
  While this may only exhibit a problem on ARM and POWER processors (as well as any other relaxed memory ordering architectures, x86 is the notable exception), it’s clearly incorrect and very non-portable.
  Don’t expect MySQL 5.7 to work properly on ARM (or POWER). Try this:

  ./mysql-test-run.pl rpl.rpl_checksum_cache --repeat=10

  You’ll likely find MySQL > 5.7.5 still explodes.
  In fact, there’s also Bug #79378 which Alexey Kopytov filed with patch that’s been sitting idle since November 2015 which is likely related to this bug.

Not covered here: universal CRC32 hardware acceleration (rather than just for innodb data pages) and other locking issues (some only recently discovered). I also didn’t go into anything filed in December 2015… although in any other project I’d expect something filed in December 2015 to have been looked at by now.

Like it or not, MySQL is still upstream for all the MySQL derivatives active today. Maybe this will change as RocksDB and TokuDB gain users and if WebScaleSQL, MariaDB and Percona can foster a better development community.