On 02/23/2012 06:02 PM, Florent Bayendrian wrote:
Hi,
I have a synchronization issue on an embedded device running Linux : if a
power shutdown is done just after a commit, sqlite will restore the
database to the previous state using the journal file. At the end of a
transaction the unlink of the journal file is not enough, the journal could
physically persist on the file system several seconds after the call to
unlink and only a sync on the directory could guarantee that the journal
file has been physically deleted. You can strace sqlite3 tool to see that
the unlink of the journal file is not followed by any sync.
The fix is simple, sqlite3OsDelete should be called with the last parameter
(dirSync) set to 1. This fix is necessary to be compliant with the last
property of an ACID database.
You're correct. The way things are now, if you commit a transaction
and then the power fails very quickly afterwards, following a reboot
you may find that your transaction has been rolled back.
And the way to fix it would be to sync the directory following the
unlink() as part of the commit.
The downside is, of course, that that extra sync will slow down all
transactions committed using "PRAGMA journal_mode=DELETE". With smallish
transactions, it would be reasonable to assume that the overhead might
be somewhere around 20-30%.
Since there is no risk of database corruption, only transaction
rollback following an unlucky power failure, we figure that the extra
durability is not worth the performance cost.
Easiest workaround would be to use either journal_mode=PERSIST or
journal_mode=WAL. Or to create a VFS shim that makes sure the syncDir
flag is set on all calls to xDelete.
Dan.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
