On 9/4/19, Simon Slavin wrote:
> On 4 Sep 2019, at 12:39pm, test user wrote:
>
>> Is it normal to get a `SQLITE_BUSY_RECOVERY`
>
> This code should only ever follow a crash,
Just to be clear, "crash" in the above statement can also mean
"program exits without calling sqlite3_close()".
--
D.
On 4 Sep 2019, at 12:39pm, test user wrote:
> Is it normal to get a `SQLITE_BUSY_RECOVERY`
This code should only ever follow a crash, or some operation which has
corrupted a database. If your hardware does not crash you should never see it.
Something is wrong.
Thanks Rowan, this is useful.
Is it normal to get a `SQLITE_BUSY_RECOVERY` response from an API when:
- No processes have crashed.
- All API uses close/finalize their db/stmt objects.
I am testing some code I wrote to make sure it retires on BUSY by creating
many processes that acquire locks
On Fri, 30 Aug 2019 at 04:18, test user
wrote:
> B. Is there any method for determining lock transitions for connections?
> - Is there an API?
> - Would it be possible to use dtrace to instrument SQLite to detect
> lock transitions?
> - Where should I be looking?
>
On unix
Just some more details to clarify the issue:
If I do a `BEGIN IMMEDIATE` on one connection, and then a `PRGAMA
journal_mode` on another, BUSY is not returned (as expected).
But if I have around 7 connections contending for a write lock via `BEGIN
IMMEDIATE`, and a different connection runs
Hello,
Im getting this message in the log:
`SQLITE_BUSY, database is locked in "PRAGMA journal_mode"`
I get this response when running the query `PRAGMA journal_mode`.
The file is in journal_mode=WAL.
Another connection holds a write transaction.
Seeing as `PRAGMA journal_mode` is just a
6 matches
Mail list logo
