Unreliable web MySQL application (Technorati/WordPress)
Technorati yesterday exposed an application error, to wit (in what presumably should be a blog content region):
WordPress database error: [Got error 28 from storage engine] SELECT DISTINCT posts.*, MATCH ( posts.post_title, posts.post_content ) AGAINST ( ‘large hadron collider bang machine scientific experiment cern bobbie big bang guardian’ ) AS mysql_score FROM wp_posts as posts LEFT JOIN wp_postmeta as postmeta ON postmeta.post_id = posts.ID WHERE posts.post_date_gmt <= ‘2008-07-01 00:26:00’ AND posts.ID <> 4369 AND ( posts.post_password = ” ) AND ( post_status = ‘publish’ OR ( post_status = ‘static’ AND postmeta.meta_value = ‘article.php’ ) ) GROUP BY posts.ID ORDER BY mysql_score DESC LIMIT 5 Today’s Guardian features a special supplement on the most incredible scientific experiment ever – the Large Hadron Collider at Cern If you liked this post / blog, buy me a BEER!
It’s been that way for about a day (which of course doesn’t mean it won’t eventually be fixed on some kind of recrawl/requery).
This kind of thing happens on the web all the time. I’m going to try to document a few cases.
Comments
6 Responses to “Unreliable web MySQL application (Technorati/WordPress)”
Leave a Reply
Just to be clear, this was not a query error in Technorati’s systems, this was in the content that Technorati crawled. Unfortunately many blogs do not degrade gracefully in the face of severe system errors. Thanks for bringing it to our attention!
-Ian
Technorati
Thanks, Ian. That kind of thing happens on blogs and CMS a lot — which kinda was my point. 😉
Best,
CAM
What happens a lot, not only on the Web, is that people who write software don’t bother to check to see whether operations actually succeeded or not.
If you’ve ever done a lot of coding, you’ll know how easy it is to make this kind of mistake. You’re thinking so hard about how the overall software works that you have to make simplifying assumptions, in order to keep your own cognitive overhead from overloading. And an easy simplifying assumption is that when you code up a call to X, at runtime X will actually happen as you expect it to.
(If you want to know what I think ought to be done about this, from a technical coding point of view, see my discussion of exceptions at http://dlweinreb.wordpress.com/2008/03/24/what-conditions-exceptions-are-really-about/)
However, doing more careful Q/A is a good idea, too!)
— Dan
So the point is, surprise, surprise … software has bugs. Um.
Is there an obvious bug in the SQL reflected back?
And the answers to kommety be?