Untraceables
I hate problems with non-obvious causes. Untraceables. Stuff like … the random wordpress annoyance. My boss’s laptop freezing intermittently. Stuff like that.
It drives me nuts… when errors are totally non-reproducible. It’s really really hard to debug them when that’s the case, you know?
I’m sitting here on my freshly innodb’ized blog, hoping that the problem was just myisam being lame … but I’ll never know for sure, unless I can reproduce the error, which apparently I can’t.
Now, computers are, as an entity, purely deterministic devices. If you put the same inputs into a computer, you _will_ get the same outputs (assuming the hardware doesn’t fail, cosmic rays don’t take over, the power stays on and any failures that do occur are handled by graceful mechanisms like ECC). The same instructions executing the same way will cause the same results. The thing is, in a busy multi-user system (like, say, rossmore.dreamhost.com, with at least 15-20 other sites hosted on it), you can never reproduce the same inputs, states and schedules. So while the system is deterministic, and all of its states and execution orders and components are deterministic, the inputs themselves are not subject to that same degree of determinism. In other words, the degree to which the system is deterministic is ultimately meaningless, because the inputs are functionally not so.
Which leads us back to the problem. What caused the database to crap itself? What caused the problem at hand? I’m pretty convinced of what the problem was, but I’m never going to know for sure. All I’ll have to go on is my hunch that InnoDB is a better storage engine than MyISAM, and that the weaknesses of MyISAM corrupted some data that InnoDB wouldn’t have. That’s sort of a meaningless assertion, I would love to have confirmation that it’s that, or denial so I could refine my mental model. But the problem is, the only thing that will confirm the assertion is if the problem doesn’t show up under innodb, ever, and does show up again if I use MyISAM exclusively instead.
Negative existence proofs are impossible. You can’t prove, without cataloging everything that exists, has existed and will exist, that something that has no fundamental reason not to exist doesn’t. You can’t disprove the existence of God, nor the existence of neutrinos, nor the existence of fire-breathing dragons. All you can do is say that within sample X, you couldn’t conclusively find evidence of God, neutrinos, or fire-breathing dragons.
I can’t prove, without first isolating the cause and mechanism of the failure, that one engine or the other is the cause or is immune to the cause. I mean, it would be possible to do so, but it would require me to basically track bugs and traces for an indeterminate amount of time, across an indeterminate amount of states. It’d be horrible, and not worth doing. So instead I’m stuck with a guess.
That’s really the whole thing though. I’m not so much “guessing” as “applying a heuristic to solve a nondeterministic problem”. I don’t know why Chihhui’s laptop was randomly freezing, so I made some guesses and tested them. I’m pretty sure it was a bad dimm, but there’s no test that’s coming back saying that that’s the case. I’m pretty sure that MyISAM corrupted a table entry somewhere and caused php to choke on it, but I can’t be positive until the same thing happens again and I can pinpoint what went wrong with it.
*mutter* stupid untraceable problems. It’s as bad as debugging a multithreaded C++ program with a poor locking implementation.