Richard Hipp wrote:
On Wed, Nov 28, 2012 at 9:58 AM, Alejandro Martínez <elpeq...@gmail.com>wrote:
And wouldn't PRAGMA read_uncommitted achieve the effect i was expecting? Or
does that cause other problems?
read_uncommitted only works if both the read and writer are in the same
process and are using shared cache.
Reading "old" or inconsistent data would not be a problem for me. (as long
as it is not corrupted data).
That's really the crux of the problem. Suppose the writer has needing to
split a btree node, for example. To do this, the writer would typically
write two new child pages and then overwrite the old b-tree page with the
parent page. If the writer were part way through this sequence when the
reader comes along, the reader would see corrupt data, since the btree
structure would be only partially updated and hence not well-formed.
That's one of the fundamental problems with update-in-place DB designs. (Aside
from their crash vulnerability and expensive crash recovery...) MVCC via
copy-on-write has none of these issues.
On Wed, Nov 28, 2012 at 11:20 AM, Richard Hipp <d...@sqlite.org> wrote:
On Wed, Nov 28, 2012 at 7:09 AM, Alejandro Martínez <elpeq...@gmail.com
wrote:
Ok, i will probably do that. Thank you.
But i'd like to know. Why doesn't this work without wal? A read only
operation shouldn't block, right?
If you are not running WAL, then the database is updated directly. That
means that there can be no readers active when a write is in progress
because then the readers would see an incomplete and uncommitted
transaction.
And regarding the commit failing, does that need a busy timeout handler
too? From documentation i though it would just wait until all readers
are
done reading and then write. And that further incoming readers would
wait
for those 5 seconds. And i was expecting not to really wait, as the
commit
should be pretty quick, right?
I'm puzzled.
On Wed, Nov 28, 2012 at 10:01 AM, Richard Hipp <d...@sqlite.org> wrote:
On Wed, Nov 28, 2012 at 6:56 AM, Alejandro Martínez <
elpeq...@gmail.com
wrote:
Is that the only way?
When i had done that in the past, the wal file grew constantly and
i
am
afraid it could fill the hard disk.
That could happen if say... one of the reading processes doesn't
properly sqlite3_reset a prepared statement after stepping it.
right?
Correct. The WAL file will grow until a checkpoint resets it. And a
checkpoint cannot reset the WAL file while there is a pending
transaction.
So if you have a statement holding a transaction open, the WAL file
will
grow without bound.
The solution there is to not hold read transactions open
indefinitely.
Call sqlite3_reset() when you are done with a statement so that its
implied
read transaction will close.
Thank you for your quick answer.
On Wed, Nov 28, 2012 at 9:52 AM, Richard Hipp <d...@sqlite.org>
wrote:
PRAGMA journal_mode=WAL
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
