Eric Bergen

I woke up this morning to a nice surprise. Peter Zaitsev from MySQL Performance Blog mentioned my fix for a crash in MySQL. Thanks Peter! That reminded me that I need to write this post about another fix.

A storage engine is called a “handler” in MySQL internals. Handler events are per row at the storage engine layer. For example an insert query that inserts 3 rows will cause one Com_insert increment and 3 handler_write increments. The way these statistics are implemented the storage engine is responsible for incrementing statistics itself. Innodb is missing function calls to increment the handler_delete and handler_update status variables. I’ve filed bug #35537 with MySQL that contains a patch adding in the missing statistic_increment calls.

It seems strange that storage engines are responsible for incrementing global statistics. Brian Aker tells me that this is because the handler interface is a direct pass through to the storage engine. I’m guessing that it was easier to do the statistics increment in the storage engine rather than chase down all the handler calls in the server and change them to functions that call the handler and increment statistics.

While working with a client we found a query that can crash MySQL. It has to do with ref_or_null outer joins where the table contains a null value. MySQL fails to tell the storage engine to initialize the index before reading from it. It crashes when used with MyISAM tables but it could result in an incorrect key file for table error with other storage engines. You can find the test case and patch in bug #34945. I’ve waited to blog about it until MySQL approved my patch. As of this writing my patch has been approved and committed for release in 5.0.60.

[Updated: 2008-03-05 Jeremy writes to tell that I left out the provenscaling.com contact form submission on the 21st and the blank email with a pdf on the 27th]
[Updated: 2008-03-26 Rob Young from MySQL AB sent me an email on the 17th saying, "We are currently working to implement PayPal to cut down on the email interactions we have in place around our manual fulfillment process. Testing is going well and we should have this implemented in the next few weeks."]

Recently Proven Scaling decided to purchase a MySQL Enterprise subscription. We will be evaluating Enterprise to see if it’s knowledge base is valuable to our customers as a supplement to Proven Scaling’s consulting services.

The subscription process seems remarkably manual on MySQL’s part. It involves them sending us five emails (not counting the mysql.com registration), all of which are from different senders. Some are from people others are automated. Here is a breakdown in chronological order:

Feb 20 12:25PM
shop@mysql.com - Online Order Confirmation

Feb 20 8:20PM
support-feedback@mysql.com - Welcome to MySQL Enterprise

Feb 20 8:49PM
enterprise-feedback@mysql.com - MySQL Enterprise: User account password changed

Feb 21 8:51AM
provenscaling.com contact form submission with creepy upsell - “Please provide my contact information to the person(s) responsible so I can assist with future orders. There are packaging options that are not available with on line purchases….”

Feb 22 10:39AM
ar@mysql.com - Your - MySQL - Invoice

Feb 22 8:41PM
rwolfejones@mysql.com - Credit Card receipt from MySql

Feb 27th 4:25pm
julie@mysql.com - MySQL receipt for Invoice

This seems a bit excessive. It also raises several questions about the registration process. Why does it take 8 hours for the order to be filled? Does someone have to manually approve the order? The second email is “Welcome to MySQL Enterprise” from support-feedback while the third email is from enterprise-feedback with notification of an account change. This email is because Enterprise generates and emails out a password on the first login.

What’s the difference between support-feedback and enterprise-feedback? A few days later after the account is setup accounts receivable sends us an invoice. Then ten hours later a credit card receipt. Why isn’t MySQL using automated credit card processing? The credit card receipt also looks like it was copied and pasted into the email.

I hope that we’re some kind of special case and that not all of the MySQL Enterprise customers have to go through the same process. I look forward to hearing comments from MySQL on this process.