[zorlem]

> And what if it's not your PhD thesis in Libre Office but a busy database server which can easily get corrupted if you don't flush.

No properly configured and working ACID compliant RDBMS should lose any data when the server is reset or stopped. If it does, then it is either a problem with the hardware, OS, configuration or the RDBMS itself. The application must also be able to handle the DB disappearing, though. Sadly this is often not the case.

[dalore]

You mean lose data after it's been committed. I can send something to the database just as it's dying and it's been lost.

[fulafel]

SQL commit is not allowed to finish before the data is safely on disk (that's the D in ACID).

[icebraining]

That's assuming that the RDBMS can tell. The disks may lie:|

[Filligree]

You should strive not to use such disks in your server. A machine reset won't power off the disks, though.

[fulafel]

Or the CPU or the memory or the OS...

[plorg]

Thus the 's' in reisub?

[kelnos]

The disk may lie. The 's' will get the OS to send everything out to the disk. Actually writing it to the platter (or flash part, or whatever) is at the disk's discretion.

[fulafel]

It's at the disk's discretion as far as the laws of physics are concerned, but this would a severely broken disk prone to losing data and if it was a major server disk vendor, the vendor would take a pretty serious hit to its reputation.

[dalore]

Yes, but my point was that I could send data to an ACID compliant server, and kill it before the commit happened and data will be lost. Just trying to point out to the parent poster that sending is not enough, you need to wait for the commiting.