The latest from the MySQL community

MySQL is known for its stability but as any other application it has bugs so it may crash sometime. Also operation system may be flawed, hardware has problems or simply power can go down which all mean similar things - MySQL Shutdown is unexpected and there could be various inconsistences. And this is not only problem as we'll see.

MySQL has angel process mysqld_safe which will restart MySQL Server in most cases. It is great, unless you have run into some bug which causes it to crash again - such crashes qucikly following one another are kind of worse because they explore many less tested code paths in MySQL and so problem potential is larger.

So lets look at the problem which happen during the crash which might need to take care of or which may seriously affect MySQL Performance.

MyISAM Corruption - If you're writting to MyISAM tables there is very large chance of them becoming corrupted …

The PostgreSQL community has done an excellent job implementing an extensible, distributed, and community-driven build farm (called pgBuildFarm), and, frankly, I'm jealous.

Benefits a Build Farm Brings (say that 10X faster)

Besides sounding cool, there are a number of very tangible benefits that a distributed build farm brings to a code project:

• Automated, consistent, and redundant tests of both common and obscure platforms
• A centralized, publicly available testing interface, which allows for an easier ability to see where failures occur, and where stable builds occur.
• Reduced costs associated with build and test tracking, which leads to quicker turn-around for builds and a more robust testing framework
• A chance for the community to be more involved in the build and testing process, resulting in a greater …

Some years ago (as penance for working at MySQL during some temporary corporate brain-damage about Free Software licensing) I began volunteering at the Free Software Foundation.

For the most part, I have spent my time providing support on Free Software licensing questions for the FSF Compliance Lab and helping out on the GPL v3 effort.

While both activities are quite rewarding, the work at the compliance lab tends to be most interesting. We serve a wide variety of people and organizations who have a correspondingly wide range of experience, views and questions. This leads to rewarding experiences, as well as experiences that are more …

I installed MySQL 5.2 today a la Markus Popp although I note his comment that it may not in fact be any different from 5.1 as yet. I have installed MySQL from source before, in the form of the 5.1 source download package. I did BK pulls of both the 5.1 and 5.2 sources, noticing that they required me to upgrade my Bison compiler, where previous builds of 5.1 worked okay with the version of Bison bundled with Slackware 10.2.

Then I went to install it on my aging Thinkpad only to have the hard drive choose this particular moment to give up the ghost. I happen to like this particular system because when people ask about what sort of footprint to expect, I point out my Thinkpad with the 300 MHz Pentium II, 64MB ram and 10GB harddrive running Slackware, Apache, MySQL and PHP. I've been using it steadily for five years and it was refurbished at …

OK, so my previous couple blog posts about prepared statements and the MySQL Query Cache, along with an excellent (as always) and in-depth coverage article on the query cache by Peter Zaitsev, have raised a number of excellent comments and discussions about the concept of prepared statements. Unfortunately, my previous blog post may have given the wrong impression about various Connectors' implementations of prepared statements and the reason why performance issues arise. This post is intended to clear up any misconceptions and begin a community discussion on what we, in the community, can do to help.

Mark Matthews, development manager of the MySQL Connectors team, and all-around cool dude, wrote me an email about some of the reasons why things are the way they are with the prepared statement implementation in the JDBC connector (and, not coincidentally, in other libraries). He pointed out that the performance issues with prepared statements …

Dave Thielen, CEO of Windward Reports and author of the excellent books "No Bugs!" and "12 Simple Secrets of Microsoft Management" has posted a very funny video on his web site called "Cubicle Wars" which is presumably what programmers focus on when they save so much time using his reporting tool.

I thought it was very clever way to show how Windward Reports saves people time.  (Disclaimer, no Windward Reports is not open …

"This email already isn't using, as far as something of necessity you have need of, so hypotenuse Your enamel on my new email address: ..."

/me sighs

About six months ago, on the recommendation of my accountants, I bought an accounting system, Mind Your Own Business. It runs under Microsoft, and I find it painful in the extreme. In the end, I decided not to use it.

On the other hand, what I was using before doesn't really cut it: as a died-in-the-wool UNIX man, I used a set of home-grown awk scripts to manipulate records which look like this:

TA#20060129#4##(2) Transfer in Brisbane
M#20060129#15.95##(3) Dinner
A#20060129#25##(4) Departure tax##NZD#0.928
M#20060129#41##(5) Lunch (Arjen, Grog)##NZD#0.928
M#20060128#25.95##(6) Dinner##NZD#0.928
M#20060126#9.5##(8) Lunch##NZD#0.928

UNIX people will recognize “intuitively” that these records consist of fields separated by a hash mark, # (and not a pound sign, £, which would be very …

A recent question in a newsgroup was

Given this table in MySQL 4.0, how can I run a single query to sort the records by the number of pipes in myfield?

id(int) -------- myfield(varchar)

1 --------- |number1|number2|
2 --------- |number1|
3 --------- |number1|number2|number3|
4 --------- |number1|number2|number3|number4|

Suppressing my urge to say something about the data structure, I suggested this clever solution from a test sample I deduced from the request:

select * from mytable;
+----+-------------------+
| id | myfield           |
+----+-------------------+
|  1 | 10|1|12|9         |
|  2 | 1|2               |
|  3 | 19|5|59|91        |
|  4 | 111|31|10|1|12|9  |
|  5 | 1|2|7             |
|  6 | 95|59|91          |
|  7 | 123456789|2000000 |
+----+-------------------+
 …

Since I started using PHP 5.x.x I started to experience incorrect time reported back through PHP using for example date(). I checked phpinfo() and found out that the default timezone was detected as America/Chicago. This was not the case as the server was configured for Canada/Saskatchewan (CST). I found out that I ended up having to directly set my timezone in php.ini file. I put the following in my php.ini file, then restarted Apache and the problem was resolved.

date.timezone = “Canada/Saskatchewan”

I’m not sure if this is a bug in PHP not detecting the timezone correctly. I tried searching through known …