Hi Dan > In both NORMAL mode, we do the following: > > 1. Write a bunch of transactions into the WAL file. > 2. fsync() the WAL file. > 3. Copy the data from the WAL file into the database file. > 4. fsync() the database file. > > If a power failure occurs at any time, the next process to read the > database scans the WAL file and attempts to read as many transactions > as possible. If the checksum fails at any point, it stops reading. > > So you can lose data. Say a power failure occurs between steps 1 > and 2 above. If your WAL had 5 unsynced transactions in it then > following recovery you may find that none, some or all of them have > survived, depending on how much of the WAL file actually made it > to disk before the power failed. >
Thank you very much for the explanation, it is very clear! I have one last question. In my ext3 file system, I have set barrier=1, disables write cache, and also set commit=1 for per second disk sync from the kernel. In your opinion, if I used NORMAL, would it mean: (1) The most number of transactions I can lose in the WAL file is 1 second's worth? (2) If the WAL contained say 10 seconds worth of transactions (1 transaction per second) before the power failure, and the 11th second the transaction failed to make it, ie stuck between your step 1 and 2, will the first 10 seconds worth of transactions still make it? I presume yes, since you have checksums in the WAL file? (3) If there is a power failure anywhere between steps 2, 3, and 4, I presume that will be OK, since the recovery will be done on next startup. If the answer is true for the above 3 questions, then I think WAL with NORMAL is an extremely attractive option to use. Regards Keith _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
