3 ms·
Unless you're talking about filesystems with specific support for atomicity, and databases with custom storage drivers for those filesystems, that's really not
by scott_karana 13y ago
Unless you're talking about filesystems with specific support for atomicity, and databases with custom storage drivers for those filesystems, that's really not fair.
It would be far too easy to kill any program mid-write().
- protomyth 13y agoA database should not be corrupt if a kill -9 is issued and it failed mid write. That is a design criteria that cannot be compromised.
- zAy0LfpBZLC8mAC 13y agoThat is what journaling is for. A database that corrupts data when you kill -9 it is garbage. A database has to survive without corruption when power fails unexpectedly, and that's even harsher than kill -9 in terms of what can go wrong if your code is sloppy.
- weland 13y ago> Unless you're talking about filesystems with specific support for atomicity, and databases with custom storage drivers for those filesystems, that's really not fair. Unless you're talking about a database not intended to be used in production, that's really not fair. What if the power comes down? The UPS blows up? There's an earthquake and the ceiling comes down? Is it OK for a DBMS to be corrupt its data then, too?
- masklinn 13y ago> Unless you're talking about filesystems with specific support for atomicity, and databases with custom storage drivers for those filesystems, that's really not fair. Yes it is. The DB should not unrecoverably corrupt itself in case of hard power loss, and a kill -9 is significanly less traumatic than a hard power loss (which includes PSU melting/explosions or UPS going down).