No confusion here, the atomicity of the FS journal guarantees that the fwrite will happen in full or not happen at all... 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
