Philip Martin wrote on Wed, 14 Apr 2010 at 12:31 +0100:
> Philip Martin <philip.mar...@wandisco.com> writes:
>
> > did that it was taking over 17s). That's an order of magnitude slower
> > which could be a problem, the SELECT on the source will block writes
> > to the database during the copy.
>
> Writing that has made me think of another solution. If we do a SELECT
> on the source database, that will block writers. At that point we can
> do a simple disk copy and be confident that the database will not
> change.
>
I see you have now implemented this (r933938; diff appended). I assume
this solution is reasonably fast (compared to the 0.25s and 3s figures
you cited upthread)?
phi...@apache.org wrote in r933938:
> +svn_sqlite__hotcopy(const char *src_path,
> + const char *dst_path,
> + apr_pool_t *scratch_pool)
> +{
> + svn_sqlite__db_t *db;
> + svn_sqlite__stmt_t *stmt;
> +
> + /* The SELECT takes a shared lock in the source database which
> + blocks writers and so ensures that the database won't change
> + during the copy.
> +
> + We could use the SQLite backup interface (from 3.6.11 and still
> + experimental) and the copy would be done in chunks with the lock
> + released between chunks. */
> + SVN_ERR(svn_sqlite__open(&db, src_path, svn_sqlite__mode_readonly,
> + statements, 0, NULL, scratch_pool, scratch_pool));
> + SVN_ERR(svn_sqlite__get_statement(&stmt, db,
> STMT_DUMMY_SELECT_FOR_BACKUP));
> + SVN_ERR(svn_sqlite__step_row(stmt));
> + SVN_ERR(svn_io_copy_file(src_path, dst_path, TRUE, scratch_pool));
I don't know the sqlite API well enough, but I trust you that doing that
copy at this point is safe. :-)
> + SVN_ERR(svn_sqlite__close(db));
> +
No __reset(). I assume the __close() makes unnecessary.
> + return SVN_NO_ERROR;
> +}
Thanks for looking into this :-)
Daniel
