Today is the day I finally encountered the “Master Bug” and it was so tiny … just one little keyword …. just a little bit too distinct.
The database admin called me and said to take a look at the statistics, I was producing an enormous amount of IO activity at certain times. We tested a few queries – nada. Then I thought to look into the logfile and there I found it at 2:44a.m. this morning, in the logfile the master bug had risen to unknown proportions, I scrolled for half a dozen or more pages until it reached the end. How many rows must a bug go down before you can call him a bug? This one sure went down a few.
What happened? Well the bug was a feature first. No really it was a bug produced by me trying to make the queries faster – what irony. Actually though the masterbug is the lovechild of a bug and a feature … the feature came, saw and mated with the bug to give birth to the master bug.
The feature of course had to do with the user input what else is able to produce problems of such a scale so consistently? The feature was to accept “null” as input for certain fields which then yield huge amounts of results when the database is queried, this was supposed to be stopped by counting the number of rows before fetching them … but if you count with distinct and then fetch rows without it under many circumstances something unexpected happens and therefore the master bug was able to fetch around 100k of rows from the table – repeatedly …. it came up to about 93MB IO per second for about 15 minutes.
So here I present the Master Bug, alas his young life as to be taken, quickly before he can make plans for further world domination. That’s what you get when you cross distinct and null at the same time ….