On Tue, 8 May 2018 at 19:23 R Smith <ryansmit...@gmail.com> wrote: > > 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". >
Given your description, if I copy all pages at once (sqlite3_backup_step with a page count of -1) I take it the later writes will not be reflected in the resultant database and that's the trade off for not locking across the full sqlite3_backup_step execution. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
