On Sun, Jan 27, 2013 at 12:21 PM, Shuki Sasson <gur.mons...@gmail.com>wrote:
> No confusion here, the atomicity of the FS journal guarantees that the > fwrite will happen in full or not happen at all... > First off, SQLite uses write(), not fwrite(). Secondly, I don't think any modern unix-like system guarantees atomicity of write() operations. You might get an atomic write under special circumstances (such as a write of exactly one sector) but not in general. Furthermore, I'm pretty sure every modern unix-like system will usually reorder the sequence of write()s so that data reaches oxide in a different order from how data was written by the application. Together, these observations go a long way to ensuring that your database files will go corrupt if you are in the middle of a transaction with PRAGMA synchronous=OFF when the power goes out, even if you are on the latest trendy journalling file system. But you are welcomed to try to prove me wrong by running the experiment yourself. > The atomicity of SQLITE is guaranteed by SQLITE mechanisms that are > completely independent of that. > However, the synchronization pragma got everything to do with the File > System fwrite mechansim and nothing to do with the SQLITE mechanism for > atomicity. > > I hope that clears things up here too.. :-) > > Shuki > > On Sun, Jan 27, 2013 at 12:11 PM, Stephan Beal <sgb...@googlemail.com > >wrote: > > > On Sun, Jan 27, 2013 at 5:53 PM, Shuki Sasson <gur.mons...@gmail.com> > > wrote: > > > > > Answer: The journal is organized in transactions that each of them is > > > atomic, so all the buffered cache changes for such operation are put > into > > > the transaction. Only fully completed transaction are replayed when the > > > system is recovering from a panic or power loss. > > > > > > > Be careful not to confuse atomic here with atomic in the SQL sense. Any > > given SQL write operation is made up of many fwrite() (or equivalent) > > calls, each of which is (in the journaling FS case) atomic in the sense > of > > the whole write() call lands stably on disk or does not, but that has > > absolutely nothing to do with the atomicity of the complete SQL-related > > write (whether that be a single field of a single record, metadata for a > > record, or a whole SQL transaction). > > > > > > > well as data it makes all the sense in the world to run with > > > synchronization = OFF and gain the additional performance benefits. > > > > > > > Good luck with that. :) > > > > -- > > ----- stephan beal > > http://wanderinghorse.net/home/stephan/ > > http://gplus.to/sgbeal > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
