One of our developers ran into the strangest error a few days ago, which neither the MySQL manual nor Google searching could find any information on. When he called certain stored procedures in a certain order, he got "Error 153 returned from storage engine." It's been reduced to a very simple test case, and a bug report has been filed. Here's the test case:

DROP TABLE IF EXISTS foo;
CREATE TABLE `foo` (
`a` int(11) NOT NULL auto_increment,
PRIMARY KEY  (`a`)
) ENGINE=InnoDB;

begin;
insert into foo values();
savepoint a1;
insert into foo values();
savepoint a2;
insert into foo values();
savepoint a1;
insert into foo values();
savepoint a2;
show warnings;
rollback;

The very last "savepoint" generates the warning "Got error 153 from storage engine". Any other MySQL'ers use savepoints and …

It turns out that there is a bug that causes replication on a 5.1 slave to fail when reading LOAD DATA statements from a 4.1-or-earlier master.

About a month ago, I set up a data warehouse for an old 4.1.21 system that can't be upgraded. I decided to use the latest 5.1 beta to take advantage of partitioning, but within the first day replication stopped rather suddenly and with a nondescript error:

[ERROR] Error running query, slave SQL thread aborted.
Fix the problem, and restart the slave SQL thread with
"SLAVE START". We stopped at log 'xxx' position xxx

Using mysqlbinlog, I compared the relay log and the masters binary log around that position, and noticed the relay log appeared corrupt! I don't recall the exact steps I took, but I isolated the problem to a LOAD DATA INFILE statement, and filed my first issue with MySQL Enterprise support.

The great folks at MySQL Support had a …

I am very confused.

I subscribe to several email lists including MySQL and Ruby on Rails lists. Generally, I keep my mailbox clean except for a folder in which I was archiving messages Ruby on Rails.

A few days ago I noticed that my Ruby on Rails folder reached 65535 messages. Today, I was looking to reply to an email from Keith Murphy (to which I had previously replied as well) and was surprised to find that the particular message didn't show up in my search. This particular message was sent on April 30 so I started scanning all my emails received on that day.

Surprisingly, I didn't find it even after a careful visual scan. Not only that, I noticed several of emails I received in the last 2 weeks missing. My initial reply to Keith was still sitting in my Sent mail folder. My trash folder also had several emails that I had deleted but not the ones that were missing.

For the life of me I …

Navicat For MySQL is a GUI for MySQL developers. I've tried a few tools before but somehow got attached to Navicat due to a few nice features that I'm not going to go into right now. Navicat suffers from a couple of annoying bugs and random crashes. I don't know if I can help fix the random ones but if I can at least file the ones I can reproduce, everyone wins. I have the latest as of today version 8.0.23.

Bug [NAL-15328]: Structure Sync Fails to notice encoding differences

Back in October last year I wrote about a peculiar MySQL error message: Can't start server: Bind on TCP/IP port: No such file or directory This error only seems to occur on Windows (Server 2003 in this case). While the first part is clear - a port could not be bound, because it was already occupied by another process - the second part does not make any sense. We got in contact about this with

One of MMM users reported that they’re experiencing really weird memory leaks in checker processes used by MMM. After a deep investigation I’ve found out that Perl part of the checker and checker modules does not leak (at least I didn’t found these leaks), so I think it could be caused by some problems in MySQL DBD module (client uses Ubuntu server).

So, I’d like to ask all users to check if their checker processes use more memory than expected and if yes, what OS, MySQL libraries versions and Perl version used on their servers.

Thanks in advance for any help.

It's not often that I get to pull Knuth's The Art of Computer Programming down off the shelf and immediately solve a problem with it. Today, I did.

A big "Thank you!" goes to my parents for giving it to me long ago.

The problem is that for the way almost all computers work, floating-point numbers do not follow the associative property. This results in wrong results and a good bit of hilarity.

A couple days ago, a mistake caused a key-value table to generate new keys for duplicate values when there should have been a unique constraint on key. This affected the stat gathering table (stats for one value are now associated with many keys) and I have to clean up the data -- while preserving the stats that have already been generated. In trying to do this, I think I found a bug in replication .... an UPDATE statement that aggregates the data produces different results on my replication slave. I've submitted a formal bug report along with SQL to duplicate the error here. I'm curious if anyone else has encountered this bug, or knows of a way to achieve the result that I want without breaking replication.

Here's a description of the test case:

Two tables store key-value pairs (in the example, `color` and `animal`), and `a_to_c` stores a relationship …