> At least this mailing list has progressed beyond "Why didn't they have > a UPS?", I suppose. :-) Yes that was my primary intend :) I'd really like people to care more about their data safety and more awareness about the problems involved.
>> 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? I simply will not delete the old original data (data state of my DB before transaction was started) that i keep just in case i will need to roll back. >> >> 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... I don't see why i need to care to write that "Ok was Ok". I just go and check if "it was Ok with original data". I don't see why i would need to have additional log file on data log file. >> 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. That's completely different problem - it is a problem of how the interface between hard drive and OS software is defined. Is there a function in this interface that will return physically written data and not cashed one. At this point no DBMS will save you indeed. >> 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. if DB is resident across several servers there should be protection from one server permanently going off line (kind of fire isn't it ?) GW> Exactly. No ACID database can ensure integerity in such a situation. GW> Postgres, Oracle, or any other transactional DB would have suffered the GW> same fate in these two cases (LiveJournal, Wiki). I can't talk about how Oracle deals with such problems because i have no access to its source code that's where mysql has a huge advantage! :) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
