3 ms·
I think you may have reinforced tptaceks's point, actually. Many DBs can handle abrupt termination.
by dwc 13y ago
I think you may have reinforced tptaceks's point, actually. Many DBs can handle abrupt termination.
- hnriot 13y agoisn't that the whole point of journaling! Of course database can handle kill -9, they are designed to. That doesn't mean it's friendly to do that because you'll pay a price in redoing journals. also -9 can leave ipc hanging so some ipcs might be needed.
- sp332 13y agoNot that the database will get corrupted, but that's a good way to lose data.
- jeltz 13y agoA database should not lose any committed data on `kill -9` in the default configuration. This is why PostgreSQL waits on fsync on the write-ahead log before completing a commit. This can be disabled with synchronous_commit off, in which case you will indeed lose data on a crash.
- marcosdumay 13y agoNormaly, it's not nice to lose uncommited data.
- zAy0LfpBZLC8mAC 13y agoI said it already elsewhere in this thread, but either the writer has other persistent storage, then it should just keep the data and retry later and nothing will be lost, or the writer doesn't have other storage, then you will also lose uncommitted data with a normal shutdown, as you can not even try to commit any data while a data base is down.