On Thu, Feb 24, 2005 at 02:38:46PM +0200, DebugasRu <[EMAIL PROTECTED]> wrote:
Probably fsync() had failed to flush some part of a 16 kB page to disk.
so what ? one of trade-offs would be to re-read the data from the disk and compare it with what it should be (another copy on the disk) and only after that fix the transaction,
That didn't get rid of the race condition, it just moved it. So now you write the transaction, and you read it off, and then you write that it was OK -- but what if that write gets interrupted?
So you write the transaction, and you read it off, and then you write that it was OK, and then you read that off, and then you write that the OK was OK. No, that could get interrupted to...
Meanwhile, it turns out that you've been reading back from cache instead of platters all along. Or perhaps it turns out that the battery-backed cache in the disk controller has a dead battery, or simply doesn't work.
If the disk promises data is written but it is not then there is nothing
MySQL can do to *tell* that something is amiss.
I think you've confused an RDBMS with a system administrator. Next thing you know you'll be complaining that MySQL isn't ACID-compliant because it can't survive a fire.
-Rich
Exactly. No ACID database can ensure integerity in such a situation. Postgres, Oracle, or any other transactional DB would have suffered the same fate in these two cases (LiveJournal, Wiki).
Greg
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
