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
