On 2018/05/08 9:37 AM, Donald Shepherd wrote:
I've long assumed that when using the online backup API on a SQLite
database, other processes will not be able to write to the source database
for the duration of the sqlite3_backup_step call. However under some
testing I've been performing, I've found that this doesn't appear to be the
case. Instead writes are prevented for a very small subset of that time,
if at all.
Is that the expected behaviour, or is there a flaw in my testing
somewhere? What defines the subset of time if it is correct?
I'm testing a WAL database if that affects it.
Expected and documented indeed. The basic rule that backup abides by is
this:
"Copy the database in a completely wholesome state to the destination."
"If the data changes (and it can) then restart the backup process from
start on the new data state."
This works well for 90% of cases, but care is to be exercised for a
really big + busy database (where writes are likely within the period of
backup), the backup can infinitely restart. If this is the case, the
controlling software needs an intervening step - and I don't think it
can be done with an immediate transaction either, because the backup too
will wait for that, but this is not tested by me, I might be wrong.
It would actually be real nice if the backup API had a parameter or flag
like "sqlite3_lockduringbackup".
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
