Thursday, July 18, 2013

Fun with Bugs #17 - Oldies but Goldies

I've just noted the date... 8 years ago I had my first official working day as a support engineer in bugs verification team of MySQL Support at MySQL AB. Why not to celebrate this anniversary with a blog post about bugs?

So, here they are, 12 oldest bugs in MySQL software that are still just "Verified" (it should mean they are accepted, but not yet fixed):
  1. Bug #2 - MySQL Connector/J doesn't make toast. I knew that Connector/J must be the most broken MySQL software (as I hate Hibernate). Now you can see how much it is broken, and nobody cares to fix it since 2002! This is a real shame...
  2. Bug #199 - Innodb autoincrement counter is lost on restart. This great report from Peter Zaitsev is still "Verified", since 2003. It became a documented "feature" in the process, but still "Verified" status means that over these years we all agree - it's broken by design! Let's hope MySQL 5.7 will fix it.
  3. Bug #363  - SHOW SESSION VARIABLES LIKE 'x' != SELECT @@SESSION.x. I spent some time verifying the original test case, and it seems in 5.6.12 it is no longer repeatable (but it seems more general things were discussed there:

    mysql> select version();
    | version() |
    | 5.6.12    |
    1 row in set (0.01 sec)

    mysql> show session variables like 'sql_log_bin';
    | Variable_name | Value |
    | sql_log_bin   | ON    |
    1 row in set (0.15 sec)

    mysql> select @@session.sql_log_bin;
    | @@session.sql_log_bin |
    |                     1 |
    1 row in set (0.00 sec)
  4. Bug #1382 (and it's later duplicate, Bug #23385, reported by my friend Tonci) - Server returns only VARCHAR as type for any metadata sent to the client. Metadata server returns had always been a problem for all MySQL connectors. Still "Verified". Now you have "Affects Me" button at least...
  5. Bug #1396 - "Lost Data with delayed insert / mysqlhotcopy or lock and flush". It was declared a feature request to implement a workaround to make this more safe. Do not use INSERT DELAYED and/or mysqlhotcopy, what else?
  6. Bug #1939 - "Wrong case sensitivity for table names when in "ANSI" mode". We all know setting lower_case_table_names=1 is the ultimate solution, and hardly this is going to change while we still have .frm files, but the bug is still "Verified".
  7. Bug #1956 - "Parser allows naming of PRIMARY KEY". Still happens with 5.6.12, and surely in SHOW CREATE TABLE you will not see the name. "One day at a time, Penny, one day at a time".
  8. Bug #2122  - "changing hostname confuses master or slave". We all know since day one with MySQL replication that binary logs should get explicit names. Let me quote one comment form the bug report though:

    [13 Sep 2007 11:54] Lars Thalmann
    We are analyzing this and will fix it after 5.1 is released. It is, unfortunately, not likely that this will be fixed in 5.1, but we prioritize it for the next version.

    Still just "Verified".
  9. Bug #2261 - "Can't use @user_variable as FETCH target in stored procedure". So, what? Just scroll down and read last comment from the best MySQL architect of all times, famous writer and bug reporter of the past, Peter Gulutzan. I was drinking wine with him near the hotel entrance last time we met (2008 AFAIR)!
  10. Bug #2742 - "fields-escaped-by only allows single character separator!". Not sure what is the status and the real problem, but look at the bug reporter's name: "Are you mortal Then prepare to die." It's the last still active bug report from this famous personality who was well known during good old times of MySQL AB.
  11. Bug #2812. When executing SHOW VARIABLES in a prepared statement stmt->field_count is 0 instead of 2. Still "Verified" and you know what these mean in the bug report: "Triaged: D2 (Serious) / R4 (High) / E4 (High)". It means that bug was considered serious, but efforts to fix and risk to introduce regressions or other problems was estimated as high. Poor MySQL connectors' developers, really...
  12. Bug #3052 - "Rollback in stored procedure doesn't close cursor". Now read the final comment:

    [22 Aug 2006 15:02] Konstantin Osipov
    This is too big to be fixed in 5.0, will be fixed in 5.1

    You know what, it's still in 5.6.12:

    mysql> select version();
    | version() |
    | 5.6.12    |
    1 row in set (0.00 sec)

    mysql> delimiter //
    mysql> create table t (s1 int) engine=InnoDB//
    Query OK, 0 rows affected (0.73 sec)

    mysql> insert into t values (55)//
    Query OK, 1 row affected (0.06 sec)

    mysql> create procedure p2 () begin
        ->   declare v int;
        ->   declare x cursor for select s1 from t;
        ->   open x;
        ->   rollback;
        ->   fetch x into v;
        ->   set @x = v;
        ->   end;//
    Query OK, 0 rows affected (0.24 sec)

    mysql> call p2()//
    Query OK, 0 rows affected (0.07 sec)
I can continue like that for days and 20 more posts... Reading (and processing) MySQL bug reports is a real fun! That's why I do it (with small breaks) for 8 years already and not going to stop. It's great reading no matter what are looking for - technical insights, workarounds, patches, hints, nice stories or just to something to laugh at.


  1. wwooww .. "it's broken by design".

    I used to say/conclude (when you were supporter at Oracle) about such (typically when an odd server behavior was 'documented') that "then it is now not only bug, but even worse, it is a documented bug". This could be one of the reasons that you characterized me as 'annoying' ( I never accepted documentation as the ultimate truth about what is right and wrong. A little common sense never harms.

    The Moon is not made from green chease. Also not if you write in 'Moon Documentation' that it is.

  2. Well, in this specific case my point was that if the bug is still "Verified" (not "Won't fix" or something like that) then we all can assume that both sides accepted this as a real problem that must be fixed. As the bug is still not fixed it seems that this broken design is now considered acceptable (and it is a documented 'feature" now).

    Anyway, the same approach to bugs processing (bug or not if documented) may look differently depending on what side are you on...

  3. The problem with the bugs database is it is different things to different people
    - used for reporting bugs
    - used for reporting feature requests
    - input from anyone and everyone
    - isolated from Oracle's own bugs system so now incomplete
    - it is hard to track related issues, the search facilities work but could be better
    - for possibly obvious commercial reasons feedback on where work may be happening or what is considered more important is not visible until after the issue is solved.
    - until recently it was hard to provide feedback on a bug if it affected you short of subscribing to changes. Oracle have added an "it affects me" button but do not provide information on the numbers behind this. I hope that gets resolved.

    I have reported several bugs but do not have an easy way to indicate if a feature is important or would be a nice to have so in the end it may be hard to extract good information out of the db.

    As for updating the documentation to reflect how mysql works rather than how it should behave without necessarily describing current behaviour as broken is rather frustrating. That just removes the desire to fix unexpected or incorrect behaviour and add more gotchas you have to work around.