On Thursday, July 22, 2010 6:14 PM, Dan Kennedy wrote:
On the other hand, if the only client connected to a database
does not disconnect cleanly (i.e. it crashes, the system crashes,
or the client exits without calling sqlite3_close()), then it
leaves the *-wal file in place. In this case,
Thanks for your explanations Dan. The new WAL feature sounds great and I'm
excited to try it. Two questions below:
When in WAL mode, clients use file-locks to implement a kind of
robust (crash-proof) reference counting for each database file.
When a client disconnects, if it is the only
On Jul 23, 2010, at 8:56 PM, Doug wrote:
Thanks for your explanations Dan. The new WAL feature sounds great
and I'm
excited to try it. Two questions below:
When in WAL mode, clients use file-locks to implement a kind of
robust (crash-proof) reference counting for each database file.
I have been reading about WAL, and there are a few questions I would
like to ask.
1) I am slightly confused about readers building the WAL index. It says
way down the page
quote:
Using an ordinary disk file to provide shared memory has the
disadvantage that it might actually do unnecessary
On Jul 22, 2010, at 6:07 PM, Alan Chandler wrote:
I have been reading about WAL, and there are a few questions I would
like to ask.
1) I am slightly confused about readers building the WAL index. It
says
way down the page
quote:
Using an ordinary disk file to provide shared memory
On Thu, Jul 22, 2010 at 12:14 PM, Dan Kennedy danielk1...@gmail.com wrote:
So one thing to bear in mind when using WAL mode is always to
call sqlite3_close() on all database handles before process
exit. Otherwise you may leave a big *-wal file in the file-system
which will need to be
On 22/07/10 17:14, Dan Kennedy wrote:
When in WAL mode, clients use file-locks to implement a kind of
robust (crash-proof) reference counting for each database file.
When a client disconnects, if it is the only client connected to
that database file, it automatically runs a checkpoint and
If I do a BEGIN, SELECT1 and at that point a writer does BEGIN
IMMEDIATE, SELECT3, UPDATE, COMMIT, and then I continue with SELECT2
COMMIT, will SELECT1 and SELECT2 have a consistent view of the
database
unaffected by the UPDATE in the middle. In other words, is the
Readers
view of how
