On Wed, Apr 13, 2011 at 10:33 AM, Simon Slavin <slav...@bigfraud.org> wrote:

>
> On 13 Apr 2011, at 12:14pm, James Green wrote:
>
> > sync=full does not work well for our app (no transactions). Far too slow.
>
> If you're not syncing, then section 3.2 of the page Richard probably
> indicates what's causing your corruption.
>

We have assumed that disabling synchronous requires a power failure or hard
reset in order to cause corruption.  But that is based on the premise that
operating system disk case is coherent.  In other words, if two processes
running on the same machine have the same disk file open, and if process A
writes pages 1 and 2, in that order, and process B reads pages 1 and 2 at
the same time, then process B will either see none of A's change, or B will
see the changes to page 1 and not page 2, or B will see both change.  It
will never be the case that B will see the changes to page 2 but not the
changes to page 1.

Can somebody please confirm for me that windows works this way?

If it turns out that I'm wrong and the windows disk cache is not coherent,
then you will indeed need to set synchronous=FULL on windows in order to
prevent corruption.  Or, perhaps we can find some magic I/O barrier system
call for windows that we can insert in place of the FlushFileBuffers() when
synchronous is OFF.  But for now, until I get better information, I'm going
to assume that he windows disk cache is indeed coherent and that none of
this is necessary.



>
> So for a while, leave that PRAGMA alone, accept that you're going to get
> slow running, and see whether this makes the corruption go away.  If it does
> then you can tackle the speed problem separately without worrying about data
> corruption.
>
> It might be worth trying to figure out whether your storage system can
> handle the speed you're expecting.  If you have multiple threads all trying
> to write at the same time can your hard disk handle that much data at that
> speed ?  If not, then that's probably why you're finding the use of 'sync'
> to be too slow.
>
> Simon.
> _______________________________________________
> 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

Reply via email to