I sat down about 20 minutes ago to write a blog post that included a link to the slides of my EMT presentation. It turned into a long post about the presentation, how I feel EMT was received and my feelings on presentations in general. Here is the short post and the link to the slides.

The MySQL conference always inspires me to write so expect a longer post in a few days.

I see three stages in the adoption and the evolution of the adoption of cloud computing:

1. Taking an existing application, and transferring it as is into a cloud provider. This is "forklifting".

2. Taking an application, and wrapping it up in cloud based provisioning and backup. This is the business space that RightScale and Zmanda help with.

3. Developing applications that implictly assume they are running in a cloud environment. I see a lot of talk of this, but not all that many running yet. But very soon they are going to be everywhere.

This week throngs of MySQL developers, users, and enthusiasts descended on silicon valley. Apparently the valley’s cooling system can’t keep up because as they arrived the outside temperature went up into the 90s (32s for those of you who choose to use a sane temperature measurement system). I’m not attending the conference this year but I almost wish I was to get some of the air conditioning. It’s supposed to cool off and rain on Saturday. As the brain power leaves I suspect the valley is going to cool and moisture in the air will condense into rain, or tears.

I bet you thought this post was going to be about Oracle and Sun, sorry. I think the weather is more interesting.

I was reading through the manual and noticed that myisamchk parallel recover option is still listed as beta code. The feature was added in 4.0.2 which was released in july 2002. This means it’s been in beta longer than gmail

While updating the mirror last week I was surprised to see that the newest MRU MySQL release is numbered 5.0.79. Previously enterprise releases had even numbers and community releases had odd numbers. I posted the question in #mysql-dev and HarrisonF was kind enough to explain it all.

MySQL 5.0 is running out of version numbers. There are limitations in mysql_get_version(), the executable comment syntax, and other places that mean MySQL can only have two digit release version numbers. MySQL Enterprise has started using odd and even version numbers to extend the life of 5.0.

This raises a few questions. What will happen to 5.0 when it runs out of release numbers? Is community going to be sacrificed to give enterprise more versions to use? Are the version restrictions going to be fixed in the future? For example if a feature is implemented in a community release the executable comment version syntax isn’t suitable for preventing it …

The #mysql-dev irc channel on freenode was created with the idea of getting the community people more involved in active discussion about mysql internals and development. When the channel was first created this happened for a few weeks and I was pretty happy to be able to observe and participate in the discussion. Now it’s mostly idle.

It seems that some people at Sun think there is still active discussion or internal developers paying attention to the channel because the GSoC web page directs people to #mysql-dev as a point of contact. The problem is there isn’t anyone there answering questions. I’ve seen quite a few people over the past few weeks ask questions that have gone unanswered. I think it’s time to restart the movement to open development and using #mysql-dev for discussion.

So it turns out that the answer to the question "when computers and television converge, what will we have" is "computers". link.

So the next question is "when computers and telephones converge, what will we have?"

I think the answer is going to also going to be "computers". Just very portable ones.

A few months ago I got a strange email from one of my clients that contained two very simple looking select queries. The only difference between the two queries is that one included the distinct keyword and the other didn’t. The strange part is that the query that used distinct returned zero rows. I spent a few days narrowing down the clients data into a small test case then created a generic test case from that. I also traced the problem to the code that decides which index to use for a group by loose index scan which can be used to resolve queries using distinct.

The example can be found in the bug and in this sql file. My patch was a step in the right direction but not complete enough to solve all the issues. Since this isn’t a crashing but I was tempted to make this blog post into one of those …

I wish I could say

        printf("%*.16xs", n, p);

where n is a size_t and p is a void*, and it would output n bytes as hex.


And I want to be able to say

        printf("%*qs", n, p);

and it would output n bytes as a C-style backslash quoted string.


Yes, I can write functions that do all this, but I have to worry about buffers, allocate buffer space, and so forth. Plus its a lot of noise and clutter, for just outputing potentially unprintable strings, often just for logging and debugging.

A feature of the MySQL server that is used a lot, and yet is a source of much user confusion, code complexity, and multiprocessor lock contention, is logging. Query logging, slow query logging, and the new 5.1 feature, "log to table".

I've removed most all of that stuff from Drizzle (and removed two or three sets of now-no-longer-necessary mutex locks in the process), and replaced it with hooks into a logging plugin subsystem, and have implemented two plugins for it. One logs to a file, and the other logs to syslog.

The output looks almost completely unlike the current MySQL logging. There are no hash-prefixed pseudocomments, for one thing. And there is no distinction between the query log and the slow query log. Queries get logged, and the amount of time each query takes gets logged with it. This subsumes the "micro-slow patch" that is spreading around in the MySQL legacy world.

The current format is …