On 19/10/2012 4:40 PM, Efim Dyadkin wrote:
Hi Richard,
You are right about the purpose of unlink but it is out of context.
There are a transaction in progress and hot journal on disk. If
journal can't be deleted by the end of transaction, the transaction
can't be considered to be successfully finished. But current
implementation of Sqlite considers this transaction as successfully
committed!
The problem with file system going down during a transaction is a real
problem that occurred to our customers. For them it was absolutely a
disaster because they lost data they had successfully saved.
I guess unixDelete must propagate ENOENT error when it runs in the
context of transaction. For applications it will be like "transaction
failed due to IO error".
For a test I tried to remove "errno != ENOENT" unconditionally from
unixDelete but immediately encountered a problem. When I tried to
execute any command on an empty database e.g. "create table a (a1
text)" I got I/O error. This is because Sqlite tried to remove
non-existsing "--wal" file
I think you're on the right track: pagerOpenWalIfPresent() attempts to
delete a file that may not exist (the comments say so!), so it should
have been expecting the occasional ENOENT.
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
