On 9/12/16, Eric Sink <e...@sourcegear.com> wrote:
> OK, this seems like a simple thing, but I'm stuck and looking for
> inspiration or clues.
>
> How can sqlite3_prepare_v2() return SQLITE_BUSY for a simple SELECT
> statement when in WAL mode?
>
> Immediately prior, a sqlite3_exec("BEGIN TRANSACTION") succeeded.
>
> The failing call is just sqlite3_prepare_v2(), and the SQL passed is
> nothing more than
>
> SELECT (explicit column list) FROM (table) WHERE (pk) = @Id
>
> So if WAL mode means writers don't block readers, it seems like preparing a
> SELECT statement should not give me error code 5. Ever?
Another process might have opened the same database with
locking_mode=EXCLUSIVE
(https://www.sqlite.org/pragma.html#pragma_locking_mode). If the
database is owned by Chrome or Firefox then that is likely the problem
because they both do that.
Or, there might have been an abnormal shutdown and some other
processes has since opened the database and is now trying to recover.
Recovery is done while holding an exclusive lock.
Or there might be some issue with your filesystem that is preventing
the processing from acquiring locks on the file.
--
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
