3 ms·

oh, but it is an important difference, i believe. any experienced developer will keep an audit log of transactions somewhere. a corrupted database can be comple

by bakhy 11y ago

oh, but it is an important difference, i believe. any experienced developer will keep an audit log of transactions somewhere. a corrupted database can be completely lost. an inconsistent one can be later corrected by using the audit trail. corruption is a really scary word to hear about a database. inconsistency is also bad, but corruption is worse, IMO. P.S. but, i must add - a DB that says it's isolated, but really isn't, and then says "but these are strange transactions", or the famous "you're doing it wrong!", that's really not cool.

masklinn 11y ago
> any experienced developer will keep an audit log of transactions somewhere. a corrupted database can be completely lost. an inconsistent one can be later corrected by using the audit trail. If you have a full audit trail you can rebuild the database from scratch so there is no difference between an inconsistent and a corrupted database. In fact, since the audit trail ought store responses from the database, replaying it may not lead to a corruption but it may lead to an inconsistent database again, or it may be rejected by the system.
- bakhy 11y ago
  good points, but it all depends on the actual situation. for starters, i was not thinking about blindly replaying it in the same system. of course that makes no sense. rather, after you find the bug, you use an alternate source of the same data to reconstruct the correct state AFTER you have fixed the bug. e.g. i had a case, where one table held state of a stock, while other held documents which were needed as proof of changes of the state. you can typically never just change things, this is not only a programmer practice, this is a standard accounting practice as well. had in my example the database gotten corrupt, that would be it [1]. but it was not, and i was able to, after finding the bug, locate exactly when and where it had happened, and correct it's effects as well. of course, this type of save will often not be possible, but i just wanted to point out that it is sometimes possible, and makes a difference. ultimately, it's just not the same. and IMO, the guy writing the call me maybe blog should not bitch about it. it's a minor, honest mistake, that can in no way reflect badly on his reliably great work. [1] while writing this, another thought came to mind - had it gotten corrupt, we would have used a backup :D not the end of the world also. but i think the distinction somewhat matters. a corrupt database is a headache for everyone, and freaks people out. business people too.
pgaddict 11y ago
The assumption that you can "fix" the database and proceed as if nothing had happened is naive, IMNSHO. Firstly, there's usually non-trivial amount of time until the inconsistency is discovered, that one modification may be easily followed by many additional modifications that are not simply commutative and "diffuse" the inconsistency to other records. For example if we're talking about bank accounts, you often get interests from that, which is not commutative with simple transfers (multiplication vs. addition). So you can't just compensate for that one error, you'd have to revert all the actions on all the involved accounts. Secondly, databases are rarely isolated. If you're handling money, chances are you've already submitted the payments to an external payment processor, or perhaps sent data somewhere else (to a different system within the bank, for example). You can't (simply) fix this. This is why people use constraints or higher transaction isolation levels, and also why the Galera response is amusing and also scary at the same time.
- bakhy 11y ago
  i am not saying it's not a problem, nor that it's always easy to fix. but it is fixable. banks will keep double records, and solutions will be found for corner cases (in the end, even write-offs). but it's simply a very different mode of failure. a corrupt database will typically fail to work, or? a system may fail due to this. this definitely costs money and nerves of all involved. but yes, the response here is bad.

by bakhy 11y ago

masklinn 11y ago

> any experienced developer will keep an audit log of transactions somewhere. a corrupted database can be completely lost. an inconsistent one can be later corrected by using the audit trail. If you have a full audit trail you can rebuild the database from scratch so there is no difference between an inconsistent and a corrupted database. In fact, since the audit trail ought store responses from the database, replaying it may not lead to a corruption but it may lead to an inconsistent database again, or it may be rejected by the system.

bakhy 11y ago
good points, but it all depends on the actual situation. for starters, i was not thinking about blindly replaying it in the same system. of course that makes no sense. rather, after you find the bug, you use an alternate source of the same data to reconstruct the correct state AFTER you have fixed the bug. e.g. i had a case, where one table held state of a stock, while other held documents which were needed as proof of changes of the state. you can typically never just change things, this is not only a programmer practice, this is a standard accounting practice as well. had in my example the database gotten corrupt, that would be it [1]. but it was not, and i was able to, after finding the bug, locate exactly when and where it had happened, and correct it's effects as well. of course, this type of save will often not be possible, but i just wanted to point out that it is sometimes possible, and makes a difference. ultimately, it's just not the same. and IMO, the guy writing the call me maybe blog should not bitch about it. it's a minor, honest mistake, that can in no way reflect badly on his reliably great work. [1] while writing this, another thought came to mind - had it gotten corrupt, we would have used a backup :D not the end of the world also. but i think the distinction somewhat matters. a corrupt database is a headache for everyone, and freaks people out. business people too.

pgaddict 11y ago

The assumption that you can "fix" the database and proceed as if nothing had happened is naive, IMNSHO. Firstly, there's usually non-trivial amount of time until the inconsistency is discovered, that one modification may be easily followed by many additional modifications that are not simply commutative and "diffuse" the inconsistency to other records. For example if we're talking about bank accounts, you often get interests from that, which is not commutative with simple transfers (multiplication vs. addition). So you can't just compensate for that one error, you'd have to revert all the actions on all the involved accounts. Secondly, databases are rarely isolated. If you're handling money, chances are you've already submitted the payments to an external payment processor, or perhaps sent data somewhere else (to a different system within the bank, for example). You can't (simply) fix this. This is why people use constraints or higher transaction isolation levels, and also why the Galera response is amusing and also scary at the same time.

bakhy 11y ago
i am not saying it's not a problem, nor that it's always easy to fix. but it is fixable. banks will keep double records, and solutions will be found for corner cases (in the end, even write-offs). but it's simply a very different mode of failure. a corrupt database will typically fail to work, or? a system may fail due to this. this definitely costs money and nerves of all involved. but yes, the response here is bad.