On 12/12/2014 03:31 AM, Nick wrote:
On 11 Dec 2014, at 10:08, Dan Kennedy wrote:
On 12/11/2014 05:49 AM, Nick wrote:
On 10 Dec 2014, at 07:35, Dan Kennedy wrote:
Strictly speaking the database file may not be well-formed even if there is no
ongoing checkpoint. If:
a) process A opens a read transaction,
b) process B opens and commits a write transaction to the database,
c) process C checkpoints the db,
then the db file considered without the *-wal file may be corrupt. The problem
comes about because process C can only checkpoint frames up until the start of
B's transaction. And there is an optimization that will prevent it from copying
any earlier frames for which there exists a frame in B's transaction that
corresponds to the same database page. So it effectively copis only a subset of
the modifications made by earlier transactions into the db file - not
necessarily creating a valid db file.
Can this corruption be detected by running PRAGMA quick_check /
integrity_check? Having the occasional backup db corrupted would be tolerable.
In many cases, but not generally. There would exist cases where a part of a
committed transaction was lost, or the values in unindexed columns where
replaced, that sort of thing.
Ok. Presumably a SQLITE_CHECKPOINT_FULL or SQLITE_CHECKPOINT_RESTART
checkpoint mode would ensure the db file is valid?
That sounds right. A successful FULL or RESTART checkpoint will always
copy entire transactions into the db.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
