Re: [sqlite] bug in SQLITE_CHECKPOINT_PASSIVE?

> I double-checked and it is possible that the checkpoint thread is > sharing an sqlite3* with a writer thread. That was the problem. I gave the SQLITE_CHECKPOINT_PASSIVE it's own sqlite3*, and it is now working fine. Thanks much. ___ sqlite-users

Re: [sqlite] bug in SQLITE_CHECKPOINT_PASSIVE?

> Are each of your threads using their own handles or do they all share the > same handle? I double-checked and it is possible that the checkpoint thread is sharing an sqlite3* with a writer thread. If so, that would account for the problem, I think. I'll look into this further and post a

Re: [sqlite] bug in SQLITE_CHECKPOINT_PASSIVE?

> > sqlite3_busy_timeout(db, 0x7000) > If you want to turn timeouts off, specify zero or a negative number. My understanding is that timeouts off means the functions immediately return BUSY. I don't want timeouts off, I want them set to infinity, so the functions never in my lifetime return

Re: [sqlite] bug in SQLITE_CHECKPOINT_PASSIVE?

Sorry I can't solve your problem (too technical for me) but I have notes on the testing code. On 5 Sep 2016, at 8:54pm, Allen wrote: > sqlite3_busy_timeout(db, 0x7000) Please don't do this. It makes things hard to read and dependent on architecture details, i.e. the

Re: [sqlite] bug in SQLITE_CHECKPOINT_PASSIVE?

On 09/06/2016 02:54 AM, Allen wrote: I'm doing some stress testing of an app that uses sqlite-amalgamation-3140100 compiled under gcc 4.8.5 (x86_64-posix-seh-rev0, Built by MinGW-W64 project) on Windows 7 x64 with the compile options: #define SQLITE_MAX_MMAP_SIZE0 #define

[sqlite] bug in SQLITE_CHECKPOINT_PASSIVE?

I'm doing some stress testing of an app that uses sqlite-amalgamation-3140100 compiled under gcc 4.8.5 (x86_64-posix-seh-rev0, Built by MinGW-W64 project) on Windows 7 x64 with the compile options: #define SQLITE_MAX_MMAP_SIZE0 #define SQLITE_OMIT_AUTORESET1 #define