I found a missing sqlite_reset call in my wrapper library, and the
solution proposed by Richard works great. So does the solution of
guarding all the sql execute calls with a mutex. I have to perform the
speed tests for the expected dataset and thread count yet. Thank you
for your help!
czw., 5 lip 2018 o 02:42 Richard Hipp <d...@sqlite.org> napisał(a):
>
> On 7/4/18, Wojtek Mamrak <wmam...@gmail.com> wrote:
> > Creating a separate connection for the SELECTs does not seem to solve
> > the problem. What is the preferred way of tackling such a scenario? I
> > guarded all the calls with a mutex, but it did not help.
>
> The change was a bug fix. Any write to an r-tree might cause the
> parts of the r-tree to be reorganized. If that where to happen while
> another thread where reading from the part being reorganized,
> incorrect answers might result.
>
> You can probably work around the problem by adding something like
> "ORDER BY +rowid" to each query against the r-tree. The "ORDER BY
> +rowid" will force the query against the rtree to run to completion on
> the first call too sqlite3_step(), storing the results in temporary
> storage (for sorting). Then result rows will be handed out via
> subsequent sqlite3_step() calls from temporary storage, rather than
> from cursors on the rtree. This approach ensures that there are no
> read cursors on rtree tables when they are written.
> --
> D. Richard Hipp
> d...@sqlite.org
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
