Thread: Whoa, what happened? (Again)

Originally Posted by grumpy

The probability of one or more defects lurking in code, just waiting to be triggered by the right set of input conditions, does tend to increase with code size. The probability also decreases as technical rigour in the development process increases, but it's very difficult to anticipate all possible error conditions or to find the causes of errors that occur quite rarely in practice (eg after a few months of up time on a site like this). And exhaustive testing is prohibitively expensive too.

I agree entirely grumpy. But my comment about the use of the /tmp partition didn't take into account the possibility of the sql server using this partition for anything else other than what's established by the engine.

That is, as far as I know, when the SQL Server engine is using this partition for its own internal operations (which include among other things the creation of temporary tables as required by an execution plan), I can't see any way a database could be corrupt, even in the face of exhaustion of storage space. The engine includes all code necessary for proper checking of write operations and it's been years since I've personally last hear of any problem in this area(*).

However, it is true that if the user of the sql engine (read, Vbulletin on this case) is also using the /tmp partition for storage of its own temporary tables and what else it feels should go there, then indeed there's a risk for corruption if that user doesn't do all the necessary write/read checks.

But then this begs the question: What on earth made Vbulletin programmers think they should use /tmp for storage of temporary tables? Or, if this is a setting on Vbulletin, why is that it is being set to /tmp?

It shouldn't. User-made temporary tables shouldn't go into /tmp.

...
(*) currently, the behavior is to terminate the server and write a log entry. All operations are rolled back and the database(s) are left intact.