This is happening in an Android app. No other process is involved, but the
filesystem there is weird, so I'm focusing on the third possibility you
mentioned.
Thanks,
--
E
On Mon, Sep 12, 2016 at 7:52 PM, Richard Hipp <d...@sqlite.org> wrote:
> 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
>
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
