With all due respect to Monty (and I mean that — much respect is due), I have some serious issues with his portrayal of the 5.1 release.  I hate to make my first entry on Planet MySQL about a controversy, but he encouraged people to blog about their experience with 5.1, so that’s what I’ll do here.

Overall Quality

As a long time user, I am very confident that the quality of 5.1 GA far exceeds that of the initial 5.0 GA release (5.0.15).  In fact, I would go further and suggest that the MySQL organization has if anything been too conservative about declaring 5.1 GA.

It’s obviously true that there are still many bugs open.  However no software is bug free, especially not those with codebase as large as MySQL.  So the question is not if they are bug free, but are the …

Anyway, it was verified independently, but there was a catch. The script in the master was using SET storage_engine=InnoDB to create the tables necessary for the test. That looked good enough to me. The script was indeed creating InnoDB tables on the master. The trouble was that the "SET" command is not replicated. Thus the …

What bug makes you to recommend upgrading most frequently ? For me it is this bug which makes it quite painful to automate various replication tasks.

It is not the most critical bug by far but this makes it worse - critical bugs would usually cause upgrades already or were worked around while such stuff as causing things like "sometimes my slave clone script does not work" may hang on for years.

Entry posted by peter | One comment

Add to: | …

How would you expect AUTO_INCREMENT to work with MERGE tables ? Assuming INSERT_METHOD=LAST is used I would expect it to work same as in case insertion happens to the last table... which does not seems to be the case. Alternatively I would expect AUTO_INCREMENT to be based off the maximum value across all tables, respecting AUTO_INCREMENT set for the Merge Table itself. Neither of these expectations really true:

PLAIN TEXT SQL:

1. mysql> CREATE TABLE a1(i int UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY);
2. Query OK, 0 rows affected (0.01 sec)
3.  
4. mysql> CREATE TABLE a2 LIKE a1;
5. Query OK, 0 rows affected (0.00 sec)
6.  
7. mysql> INSERT INTO a1 VALUES(2);
8. Query OK, 1 row affected (0.00 …

Over a year ago I wrote about pretty nasty Innodb Recovery Bug. I ran in the same situation again (different system, different customer) and went to see the status of the bug... and it is still open.

You may thing it is minor issue but in fact with large buffer pool this bug makes database virtually unrecoverable (if 10% of progress in 2hours qualifies as that). It is especially nasty as it is quite hard to predict. Both customers had MySQL crash recovery happening in reasonable time... most of the times until they run into this problem.

So what is the point ? Have modest expectations about when your favorite MySQL bugs are fixed (This is actually Innodb one, so Innobase/Oracle is responsible for fixing it not MySQL/Sun but there are …

I don’t know about “me too” types of bug replies, but before everyone goes to the bug database and starts saying “me too”, “this affects me”, “please fix this ASAP”, “I won’t use MySQL 5.1 till this is fixed”, I wonder if this will cause more harm (i.e. more bug spam for the developer, and all those subscribed to it) than good.

It seems like the public Worklog interface gets this right - via voting. Having a count of those that have the same problems, even displayed via “stars”, is a much better interface, and shows urgency a lot better than “me too” posts.

Take one of my favourite worklogs - …

my “mysql client fixes” branch on launchpad contains fixes for eleven bugs (nine of them reported on bugs.mysql.com).

don’t get too excited — these are all the lowest priority-level bugs, mostly typos in comments and documentation.

now i have to figure out the latest process for actually getting these changes into the official tree. there are different policies around how and when to push to trees since i was last doing any server development. from someone who is partially outside, it all seems very tedious and designed to make it impossible to fix anything. process gone bad.

the mysql server isn’t going to get the benefits of using a good, …

This is a short reply to Michael’s post “A bugs life”.

This bugs are still relevant for me:

1. Bug #9588 Support for ALTER (or CREATE OR REPLACE) PROCEDURE/FUNCTION <BODY>
2. Bug #18466 add REPLACE to CREATE FUNCTION, PROCEDURE, TRIGGER
3. Bug #33455 Can’t retrieve Routine Parameters if the user has limited privileges

In my dreamland they would be fixed before 5.1 reaches GA but I know that probably it is difficult to add such features in a RC version.

Questions. Do you plan to fix them? If yes, can I ask you when?

Thanks.
 

According to the manual, FLUSH LOGS is supposed to:

Closes and reopens all log files. If binary logging is enabled, the sequence number of the binary log file is incremented by one relative to the previous file. On Unix, this is the same thing as sending a SIGHUP signal to the mysqld server (except on some Mac OS X 10.3 versions where mysqld ignores SIGHUP and SIGQUIT).

If the server is writing error output to a named file (for example, if it was started with the –log-error option), FLUSH LOGS causes it to rename the current error log file with a suffix of -old and create a new empty log file. No renaming occurs if the server is not writing to a named file (for example, if it is writing errors to the console).

There is a bug, however. In the case when the error log writes to a non-default path, FLUSH LOGS actually does not work as specified …

i was going to write some reactions to an observation that postgresql has no bug tracker and its discussion last week, but lost the spark and abandoned the post after a few days. but today i ran across a quote from linus torvalds that neatly sums up my thoughts:

We’ve always had some pending/unresolved issues, and I think that as our tracking gets better, there’s likely to be more of them. A number of bug-reports are either hard to reproduce (often including from the reporter) or end up without updates etc.

before there was a bug tracking system for mysql, there was a claim that all bugs were fixed in each release (or documented), and there has been a lot of pain in seeing how well that sort of claim stacks up against a actual …