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
[Read more]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:
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 …
[Read more]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 - …
[Read more]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, …
[Read more]This is a short reply to Michael’s post “A bugs life”.
This bugs are still relevant for me:
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 …
[Read more]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 …
[Read more]Zack Urlocker says MySQL 5.1 has zero bugs. He may have been misquoted, or quoted out of context, but there it is. I’ll quote enough of it that you can’t take it out of context twice:
Mickos also said MySQL 5.1 has upgraded its reliability and ease of use over 2005’s v5.0.
“Now we can admit it, but this version is much improved over 5.0, which we weren’t totally happy with,” Mickos confided.
He reported that more than 1,300 bugs (997 in 2007, 386 so far in 2008) have been fixed in v5.1, and that, according to standard DBT2 benchmarks, the performance of v5.1 is 10 to 15 percent better than the previous version.
“This version now has zero bugs,” Urlocker told eWEEK.
You can check for yourself at the MySQL bug …
[Read more]yeah, it is all odbc, all the time here, it seems. that is just because i can’t write about the really exciting stuff. soon!
that is not to say that releasing mysql connector/odbc 5.1.3-rc is not a huge milestone! it took us a while to get there, but we finally have a unicode-aware odbc driver that is, in our opinions, production-ready. now we just need some community feedback to find out if we are right. there are a few minor issues we know about already, but the impact of those is generally small enough that the majority of folks should not have any problems.