Showing entries 101 to 110 of 117
« 10 Newer Entries | 7 Older Entries »
Displaying posts with tag: bugs (reset)
Nov
28
2008
Yet another replication trap
Posted by Giuseppe Maxia on Fri 28 Nov 2008 13:38 UTC
Tags:



When I filed Bug#39197 replication breaks with large load with InnoDB, flush logs, and slave stop/start, I genuinely thought that it was a serious problem. I was a bit puzzled, to tell the truth, because the scenario that I was using seemed common enough for this bug to be found already.

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 …

[Read more]
Sep
12
2008
What Bugs makes you to recomend upgrade most frequently ?
Posted by MySQL Performance Blog on Fri 12 Sep 2008 22:09 UTC
Tags:

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: | …

[Read more]
Sep
12
2008
AUTO_INCREMENT and MERGE TABLES
Posted by MySQL Performance Blog on Fri 12 Sep 2008 02:15 UTC
Tags:

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 …
[Read more]
Sep
05
2008
How quickly you should expect to see bugs fixed
Posted by MySQL Performance Blog on Fri 05 Sep 2008 01:24 UTC
Tags:

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]
Jul
22
2008
?Me too? comments in bug systems
Posted by Colin Charles on Tue 22 Jul 2008 23:58 UTC
Tags:

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]
Jul
22
2008
how to fix eleven bugs in mysql 5.1
Posted by Jim Winstead on Tue 22 Jul 2008 05:58 UTC
Tags:

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]
Jul
17
2008
RE: A bugs life
Posted by Santo Leto on Thu 17 Jul 2008 15:45 UTC
Tags:

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.
 

Jun
06
2008
When FLUSH LOGS Fails Silently
Posted by Sheeri K. Cabral on Fri 06 Jun 2008 14:16 UTC
Tags:

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]
May
05
2008
bug tracking and code review
Posted by Jim Winstead on Mon 05 May 2008 22:03 UTC
Tags:

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]
May
03
2008
News flash: MySQL 5.1 has zero bugs
Posted by Baron Schwartz (xaprb) on Sat 03 May 2008 00:54 UTC
Tags:

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]
Showing entries 101 to 110 of 117
« 10 Newer Entries | 7 Older Entries »