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

Reply via email to