[sqlite] db corruption with wal on xfs

[Michael Barton]

I've been playing around with WAL journaling on sqlite 3.7.2 (the
build from Ubuntu Maverick).  I consistently get corrupted dbs when I
use synchronous=NORMAL and journal_mode=WAL on XFS with multiple
concurrent writers.  If I change either of those pragmas or run it on
ext3, I don't seem to have any problems.

Here's my little repro in python:

---

import sqlite3, time, os, multiprocessing, uuid

def connect():
    conn = sqlite3.connect('./test.db', timeout=60.0)
    conn.execute('PRAGMA synchronous = NORMAL')
    conn.execute('PRAGMA journal_mode = WAL')
    return conn

connect().execute("CREATE TABLE object (name TEXT UNIQUE);")

def insert_items():
    while True:
        conn = connect()
        conn.execute('''
            INSERT INTO object (name) VALUES (?)
        ''', (uuid.uuid4().hex,))
        conn.commit()

for x in xrange(10):
    proc = multiprocessing.Process(target=insert_items)
    proc.daemon = True
    proc.start()

while True:
    print len(list(connect().execute('select * from object order by name')))
    time.sleep(5)

---

Running this, I get something along the lines of:

n...@cfsyn27:/mnt/sdb1$ python reproduce.py
11
3643
7479
Traceback (most recent call last):
  File "reproduce.py", line 25, in 
    print len(list(connect().execute('select * from object order by name')))
sqlite3.DatabaseError: database disk image is malformed


Any thoughts?

-- Michael Barton
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] DB Corruption

[ramesh.kotabagi]

Hi All,
 
 
I'm Ramesh, currently we are using sqlite-3.5.8 version,
mainly(sqlite3.h and sqlite3.c) files
API to perform DB operations like 1) insert to,
  2) delete from,
  3) select from,
4)
update,
 
we are seeing DB corruption( error #define SQLITE_CORRUPT 11   /*
The database disk image is malformed */)
so often in our software, 
 
Platform: montavista(linux)
Language: C++
 
Please help me to come out of this issue, this is very critical for our
software,
 
Thanks in adv.

Thanks and Regards,
Ramesh

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email. 

www.wipro.com
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] db corruption with zero bytes

[Evilsmile]

The data encoding is UTF-8, and our platform is Linux.


On 12月23日, 上午6時23分, Max Vlasov  wrote:
> On Tue, Dec 22, 2009 at 1:22 PM, Evilsmile  wrote:
> > Hello,
>
> > My sqlite version is 3.5.1 and there are a lot of db corruption in my
> > system.
>
> Please, let us know more about your language/platform
> ___
> sqlite-users mailing list
> sqlite-us...@sqlite.orghttp://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

Re: [sqlite] db corruption with zero bytes

[Max Vlasov]

On Tue, Dec 22, 2009 at 1:22 PM, Evilsmile  wrote:

> Hello,
>
> My sqlite version is 3.5.1 and there are a lot of db corruption in my
> system.
>
>

Please, let us know more about your language/platform
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] db corruption with zero bytes

[Evilsmile]

Hello,

My sqlite version is 3.5.1 and there are a lot of db corruption in my
system.
Given the following pragma integrity_check output:
> sqlite> pragma integrity_check;
> *** in database main ***
> Page 236054 is never used
> Page 236055 is never used
> rowid 0 missing from index sqlite_autoindex_aggr_log_1
> rowid 17 missing from index sqlite_autoindex_aggr_log_1
> rowid 21 missing from index sqlite_autoindex_aggr_log_1

I try to use UltraEdit to open the these corrupted databases with
hexadecimal mode, and find there are two situations.
1) There are 8 zero bytes in the record.
2) There are 8 zero bytes in the record header.

When using "select * from table" command, it will read data from table
until the zero bytes. And the sqlite of version 3.5.1 can read more
data from corrupted db than version 3.6.20. (When using ".dump"
command, the sqlite of version 3.5.1 will dump almost data from db and
version will dump a little.)
PS: the data is created by sqlite of version 3.5.

I have no idea about what happened. Is there any fix after version
3.5.1 about this situation? or what can I do?
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] DB Corruption

[Simon Slavin]

On 2 Oct 2009, at 2:13pm, Reusche, Andrew wrote:

> sqlite> pragma integrity_check;
>
> wrong # of entries in index sales_datetime

Which version of SQLite are you using ?

DROP the index then MAKE it again, then do the 'PRAGMA  
integrity_check' thing again.

If that didn't help I suspect that that table (or maybe the entire  
database) is terminally corrupt somehow.  Using the command-line tool  
on that database (take a backup copy first):

Dump all the data from that table using .dump .
DROP the table.
Read the dump you made using .read .

Do the 'PRAGMA integrity_check' thing again.  If it's still bad,

Dump all the data from all tables using .dump .
Quit the tool.  Delete your database file.  Start the tool up again  
(it'll make a blank database file for you)
Read the dump you made using .read .

If you're using a recent version of SQLite please keep a copy of the  
corrupt database file: someone on this list might be interested in  
looking at it for debugging purposes.

For more information on the command-line tool see



Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] DB Corruption

[Pavel Ivanov]

> So any idea what might have caused this, a good way to fix it, or detect
> it at runtime?  The other threads that I have read point to either
> multithreading issues, or an ungraceful shutdown.

And they're right, except that ungraceful shutdown will hurt your
database only if you set pragma synchronous = off and multithreading
issues will hurt if you compiled SQLite with threading turned off and
then tried to use SQLite from multiple threads...

And there's not much you can do about the problems themselves. Just
try to .dump it from sqlite3 command line utility and recreate
database from the dump. And don't think about detecting such problems
in runtime, think about fixing your application so that these problems
don't appear.


Pavel

On Fri, Oct 2, 2009 at 9:13 AM, Reusche, Andrew
 wrote:
> I have an issue with a sqlite3 db.  I have a table that yields invalid
> data in some queries.
>
>
>
>
>
> Select sales.*
>
> From sales
>
> Where sales.record_type = 1
>
> Order By sales.datetime Desc
>
>
>
> Yields the top 124 or so records as all duplicates, and the record_type
> column has a "0" in each record.  By the query above, these shouldn't
> show.  What's worse is that there is really only one instance of this
> record in the row:
>
>
>
> Select sales.*, sales.sales_id
>
> From sales
>
> Where sales.sales_id = 617284
>
> Order By sales.datetime Desc
>
>
>
> This query yields 1 value.  The original query in this email returned
> 124 copies of this record.
>
>
>
> More troubleshooting:
>
>
>
> sqlite> select max(sales_id) from sales;
>
> 617283
>
>
>
> This value returned for max is actually less than the value returned in
> the query with the bogus results.
>
>
>
> sqlite> pragma integrity_check;
>
> rowid 609189 missing from index sales_datetime
>
> rowid 609190 missing from index sales_datetime
>
> rowid 609191 missing from index sales_datetime
>
> rowid 609192 missing from index sales_datetime
>
> rowid 609193 missing from index sales_datetime
>
> rowid 609194 missing from index sales_datetime
>
> rowid 609195 missing from index sales_datetime
>
> rowid 609196 missing from index sales_datetime
>
> rowid 609197 missing from index sales_datetime
>
> rowid 609198 missing from index sales_datetime
>
> rowid 609199 missing from index sales_datetime
>
> rowid 609200 missing from index sales_datetime
>
> rowid 609201 missing from index sales_datetime
>
> rowid 609202 missing from index sales_datetime
>
> rowid 609203 missing from index sales_datetime
>
> rowid 609204 missing from index sales_datetime
>
> rowid 609198 missing from index sales_datetime
>
> rowid 609199 missing from index sales_datetime
>
> rowid 609200 missing from index sales_datetime
>
> rowid 609201 missing from index sales_datetime
>
> rowid 609202 missing from index sales_datetime
>
> rowid 609203 missing from index sales_datetime
>
> rowid 609204 missing from index sales_datetime
>
> rowid 625656 missing from index sales_datetime
>
> rowid 625657 missing from index sales_datetime
>
> rowid 625658 missing from index sales_datetime
>
> rowid 625661 missing from index sales_datetime
>
> rowid 625662 missing from index sales_datetime
>
> rowid 625663 missing from index sales_datetime
>
> rowid 625664 missing from index sales_datetime
>
> rowid 625665 missing from index sales_datetime
>
> rowid 625666 missing from index sales_datetime
>
> wrong # of entries in index sales_datetime
>
>
>
> then I run reindex.  Then another integrity_check:
>
>
>
>
>
> sqlite> pragma integrity_check;
>
> wrong # of entries in index sales_datetime
>
>
>
>
>
>
>
> So any idea what might have caused this, a good way to fix it, or detect
> it at runtime?  The other threads that I have read point to either
> multithreading issues, or an ungraceful shutdown.
>
>
>
>
>
> Thanks in advance
>
>
>
>
>
> Andrew
>
>
>
> This communication (including any attachments) is intended for the use of the 
> intended recipient(s) only and may contain information that is confidential, 
> privileged or legally protected. Any unauthorized use or dissemination of 
> this communication is strictly prohibited. If you have received this 
> communication in error, please immediately notify the sender by return e-mail 
> message and delete all copies of the original communication. Thank you for 
> your cooperation.
> ___
> 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

[sqlite] DB Corruption

[Reusche, Andrew]

I have an issue with a sqlite3 db.  I have a table that yields invalid
data in some queries.  

 

 

Select sales.*

>From sales

Where sales.record_type = 1

Order By sales.datetime Desc

 

Yields the top 124 or so records as all duplicates, and the record_type
column has a "0" in each record.  By the query above, these shouldn't
show.  What's worse is that there is really only one instance of this
record in the row:

 

Select sales.*, sales.sales_id

>From sales

Where sales.sales_id = 617284

Order By sales.datetime Desc

 

This query yields 1 value.  The original query in this email returned
124 copies of this record.

 

More troubleshooting:

 

sqlite> select max(sales_id) from sales;

617283

 

This value returned for max is actually less than the value returned in
the query with the bogus results.

 

sqlite> pragma integrity_check;

rowid 609189 missing from index sales_datetime

rowid 609190 missing from index sales_datetime

rowid 609191 missing from index sales_datetime

rowid 609192 missing from index sales_datetime

rowid 609193 missing from index sales_datetime

rowid 609194 missing from index sales_datetime

rowid 609195 missing from index sales_datetime

rowid 609196 missing from index sales_datetime

rowid 609197 missing from index sales_datetime

rowid 609198 missing from index sales_datetime

rowid 609199 missing from index sales_datetime

rowid 609200 missing from index sales_datetime

rowid 609201 missing from index sales_datetime

rowid 609202 missing from index sales_datetime

rowid 609203 missing from index sales_datetime

rowid 609204 missing from index sales_datetime

rowid 609198 missing from index sales_datetime

rowid 609199 missing from index sales_datetime

rowid 609200 missing from index sales_datetime

rowid 609201 missing from index sales_datetime

rowid 609202 missing from index sales_datetime

rowid 609203 missing from index sales_datetime

rowid 609204 missing from index sales_datetime

rowid 625656 missing from index sales_datetime

rowid 625657 missing from index sales_datetime

rowid 625658 missing from index sales_datetime

rowid 625661 missing from index sales_datetime

rowid 625662 missing from index sales_datetime

rowid 625663 missing from index sales_datetime

rowid 625664 missing from index sales_datetime

rowid 625665 missing from index sales_datetime

rowid 625666 missing from index sales_datetime

wrong # of entries in index sales_datetime

 

then I run reindex.  Then another integrity_check:

 

 

sqlite> pragma integrity_check;

wrong # of entries in index sales_datetime

 

 

 

So any idea what might have caused this, a good way to fix it, or detect
it at runtime?  The other threads that I have read point to either
multithreading issues, or an ungraceful shutdown.

 

 

Thanks in advance

 

 

Andrew

 

This communication (including any attachments) is intended for the use of the 
intended recipient(s) only and may contain information that is confidential, 
privileged or legally protected. Any unauthorized use or dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the sender by return e-mail message and 
delete all copies of the original communication. Thank you for your cooperation.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] DB corruption, unit tests

[Joe Wilson]

I've seen something like this happen before when fsync() did not 
work correctly on a platform, and subsequent fstat() calls returned 
erroneous information.

In any event, see if your NFS server is using async IO for its writes. 
It probably is, as async is the default and is much faster - but it's 
also less safe. 

Try mounting NFS with sync and rerun the tests.
Even if it works, the speed (or lack thereof) may make it unusable.

http://www.troubleshooters.com/linux/nfs.htm

--- Arun Bhalla <[EMAIL PROTECTED]> wrote:
> Arun Bhalla wrote:
> > 2) In order to help diagnose the problem, we ran some unit tests, and we 
> > had some unusual results:
> 
> >   c) On a Linux/x86 VM (running under Windows), some tests fail.  I 
> > don't have the specifics at the moment, but that would be cause for 
> > alarm, particularly the failures are above (a) and (b), assuming those 
> > are not problematic.
> 
> Here are the test failures.  It looks like to me that the NFS 
> implementation is the problem and not SQLite, but if someone can confirm 
> one way or the other or provide hints, that would be great.
> 
>  From SQLite 3.4.1:
> 
> avtrans-9.2.1-1024...
> Expected: [1024 67941cd790716d4a63548cd51aa51707]
>   Got: [404 624f6573af0850effc03dad438a7bb22]
> avtrans-9.2.2-1024...
> Expected: [1024 67941cd790716d4a63548cd51aa51707]
>   Got: [400 32e7ee7933bb9daedb9beebd4ee3b6e9]
> avtrans-9.2.3-1024... Ok
> avtrans-9.2.4-1024... Ok
> avtrans-9.2.5-1024... Ok
> avtrans-9.3.1-434...
> Expected: [434 61b0d88626a9cfb71469d42bbce87c2d]
>   Got: [415 5453c0f719486ccee158ec7690caa467]
> avtrans-9.3.2-434...
> Expected: [434 61b0d88626a9cfb71469d42bbce87c2d]
>   Got: [418 9727721910a7c205200e90b7c1407f15]
> avtrans-9.3.3-434... Ok
> avtrans-9.3.4-434... Ok
> avtrans-9.3.5-434... Ok
> avtrans-9.4.1-449...
> Error: database disk image is malformed
> avtrans-9.4.2-449...
> Error: cannot start a transaction within a transaction
> avtrans-9.4.3-449...
> Error: database disk image is malformed
> avtrans-9.4.4-449... Ok
> avtrans-9.4.5-449... Ok
> /nfs/t/sqlite-3.4.1/.libs/lt-testfixture: database disk image
> is malformed
>  while executing
> "db eval {SELECT count(*), md5sum(x) FROM t3}"
>  (procedure "signature" line 2)
>  invoked from within
> "signature"
>  ("for" body line 2)
>  invoked from within
> "for {set i 2} {$i<=$limit} {incr i} {
>set ::sig [signature]
>set cnt [lindex $::sig 0]
>if {$i%2==0} {
>  execsql {PRAGMA fullfsync=ON}
>} else ..."
>  (file "./test/avtrans.test" line 863)
>  invoked from within
> "source $testfile"
>  ("foreach" body line 5)
>  invoked from within
> "foreach testfile [lsort -dictionary [glob $testdir/*.test]] {
>  set tail [file tail $testfile]
>  if {[lsearch -exact $EXCLUDE $tail]>=0} continue
> ..."
>  ("for" body line 7)
>  invoked from within
> "for {set Counter 0} {$Counter<$COUNT && $nErr==0} {incr Counter} {
>if {$Counter%2} {
>  set ::SETUP_SQL {PRAGMA default_synchronous=off;}
>} else ..."
>  (file "./test/all.test" line 85)
> make: *** [fulltest] Error 1
> 
>  From SQLite 3.5.2:
> 
> avtrans-9.1...
> Error: database disk image is malformed
> /nfs/t/src/sqlite-3.5.2/.libs/lt-testfixture: database disk
> image is malformed
>  while executing
> "db eval {SELECT count(*), md5sum(x) FROM t3}"
>  (procedure "signature" line 2)
>  invoked from within
> "signature"
>  ("for" body line 2)
>  invoked from within
> "for {set i 2} {$i<=$limit} {incr i} {
>set ::sig [signature]
>set cnt [lindex $::sig 0]
>if {$i%2==0} {
>  execsql {PRAGMA fullfsync=ON}
>} else ..."
>  (file "./test/avtrans.test" line 865)
>  invoked from within
> "source $testfile"
>  ("foreach" body line 5)
>  invoked from within
> "foreach testfile [lsort -dictionary [glob $testdir/*.test]] {
>  set tail [file tail $testfile]
>  if {[lsearch -exact $EXCLUDE $tail]>=0} continue
> ..."
>  ("for" body line 7)
>  invoked from within
> "for {set Counter 0} {$Counter<$COUNT && $nErr==0} {incr Counter} {
>if {$Counter%2} {
>  set ::SETUP_SQL {PRAGMA default_synchronous=off;}
>} else ..."
>  (file "./test/all.test" line 83)
> make: *** [fulltest] Error 1



  

Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.  
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DB corruption, unit tests

[Arun Bhalla]

Arun Bhalla wrote:
2) In order to help diagnose the problem, we ran some unit tests, and we 
had some unusual results:


  c) On a Linux/x86 VM (running under Windows), some tests fail.  I 
don't have the specifics at the moment, but that would be cause for 
alarm, particularly the failures are above (a) and (b), assuming those 
are not problematic.


Here are the test failures.  It looks like to me that the NFS 
implementation is the problem and not SQLite, but if someone can confirm 
one way or the other or provide hints, that would be great.


From SQLite 3.4.1:

avtrans-9.2.1-1024...
Expected: [1024 67941cd790716d4a63548cd51aa51707]
 Got: [404 624f6573af0850effc03dad438a7bb22]
avtrans-9.2.2-1024...
Expected: [1024 67941cd790716d4a63548cd51aa51707]
 Got: [400 32e7ee7933bb9daedb9beebd4ee3b6e9]
avtrans-9.2.3-1024... Ok
avtrans-9.2.4-1024... Ok
avtrans-9.2.5-1024... Ok
avtrans-9.3.1-434...
Expected: [434 61b0d88626a9cfb71469d42bbce87c2d]
 Got: [415 5453c0f719486ccee158ec7690caa467]
avtrans-9.3.2-434...
Expected: [434 61b0d88626a9cfb71469d42bbce87c2d]
 Got: [418 9727721910a7c205200e90b7c1407f15]
avtrans-9.3.3-434... Ok
avtrans-9.3.4-434... Ok
avtrans-9.3.5-434... Ok
avtrans-9.4.1-449...
Error: database disk image is malformed
avtrans-9.4.2-449...
Error: cannot start a transaction within a transaction
avtrans-9.4.3-449...
Error: database disk image is malformed
avtrans-9.4.4-449... Ok
avtrans-9.4.5-449... Ok
/nfs/t/sqlite-3.4.1/.libs/lt-testfixture: database disk image
is malformed
while executing
"db eval {SELECT count(*), md5sum(x) FROM t3}"
(procedure "signature" line 2)
invoked from within
"signature"
("for" body line 2)
invoked from within
"for {set i 2} {$i<=$limit} {incr i} {
  set ::sig [signature]
  set cnt [lindex $::sig 0]
  if {$i%2==0} {
execsql {PRAGMA fullfsync=ON}
  } else ..."
(file "./test/avtrans.test" line 863)
invoked from within
"source $testfile"
("foreach" body line 5)
invoked from within
"foreach testfile [lsort -dictionary [glob $testdir/*.test]] {
set tail [file tail $testfile]
if {[lsearch -exact $EXCLUDE $tail]>=0} continue
..."
("for" body line 7)
invoked from within
"for {set Counter 0} {$Counter<$COUNT && $nErr==0} {incr Counter} {
  if {$Counter%2} {
set ::SETUP_SQL {PRAGMA default_synchronous=off;}
  } else ..."
(file "./test/all.test" line 85)
make: *** [fulltest] Error 1

From SQLite 3.5.2:

avtrans-9.1...
Error: database disk image is malformed
/nfs/t/src/sqlite-3.5.2/.libs/lt-testfixture: database disk
image is malformed
while executing
"db eval {SELECT count(*), md5sum(x) FROM t3}"
(procedure "signature" line 2)
invoked from within
"signature"
("for" body line 2)
invoked from within
"for {set i 2} {$i<=$limit} {incr i} {
  set ::sig [signature]
  set cnt [lindex $::sig 0]
  if {$i%2==0} {
execsql {PRAGMA fullfsync=ON}
  } else ..."
(file "./test/avtrans.test" line 865)
invoked from within
"source $testfile"
("foreach" body line 5)
invoked from within
"foreach testfile [lsort -dictionary [glob $testdir/*.test]] {
set tail [file tail $testfile]
if {[lsearch -exact $EXCLUDE $tail]>=0} continue
..."
("for" body line 7)
invoked from within
"for {set Counter 0} {$Counter<$COUNT && $nErr==0} {incr Counter} {
  if {$Counter%2} {
set ::SETUP_SQL {PRAGMA default_synchronous=off;}
  } else ..."
(file "./test/all.test" line 83)
make: *** [fulltest] Error 1



Thanks,
Arun

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] DB corruption, unit tests

[drh]

Arun Bhalla <[EMAIL PROTECTED]> wrote:
> Hello there,
> 
> I have a couple related questions:
> 
> 1) Is anyone aware of any recent cases of SQLite DB corruption? 

All known database corruption issues are described at

   http://www.sqlite.org/cvstrac/wiki?p=DatabaseCorruption

Additional information on how SQLite implements ACID transactions
and suggested ways of subverting can be found at

   http://www.sqlite.org/atomiccommit.html

--
D. Richard Hipp <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

[sqlite] DB corruption, unit tests

[Arun Bhalla]

Hello there,

I have a couple related questions:

1) Is anyone aware of any recent cases of SQLite DB corruption?  We 
upgraded from SQLite 3.3.6 to SQLite 3.4.1 a few months ago.  In the 
last couple days, we've encountered a couple cases of SQLite reporting 
that a DB file had become corrupted ("database disk image is 
malformed").  I believe that both cases involved writing to NFS. 
However, we use our own locking mechanism to handle some faulty NFS 
implementations regarding locking and fcntl().


In one case, only a single (unthreaded) process was accessing the 
database over NFS.  However, that process was running in a Linux VMware 
virtual machine.  Less is known about the other case, but it was also 
running in Linux (not running in a VM) while writing to NFS.  Both cases 
involve NetApp boxes (but not the same one).


Aside from NFS locking issues, I'm not aware of any issues involving 
SQLite and NFS.  Since one case didn't involve concurrency, perhaps 
there's another problem.


2) In order to help diagnose the problem, we ran some unit tests, and we 
had some unusual results:


  a) On a native Linux/x86 system, the lock4-1.3 test for SQLite 3.4.1 
will fail intermittently, both on NFS and local disk.  Is the test not 
very robust?  Perhaps there's a race condition?


  b) On a native Linux/AMD64 system, the io-4.2.2 test for SQLite 3.5.2 
will fail regularly on both local disk and NFS.  Is this cause for concern?


  c) On a Linux/x86 VM (running under Windows), some tests fail.  I 
don't have the specifics at the moment, but that would be cause for 
alarm, particularly the failures are above (a) and (b), assuming those 
are not problematic.


Thanks,
Arun

-
To unsubscribe, send email to [EMAIL PROTECTED]
-