On Wed, Nov 28, 2012 at 9:58 AM, Alejandro Martínez <[email protected]>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. > > > On Wed, Nov 28, 2012 at 11:20 AM, Richard Hipp <[email protected]> wrote: > > > On Wed, Nov 28, 2012 at 7:09 AM, Alejandro Martínez <[email protected] > > >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 <[email protected]> wrote: > > > > > > > On Wed, Nov 28, 2012 at 6:56 AM, Alejandro Martínez < > > [email protected] > > > > >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 <[email protected]> > > wrote: > > > > > > > > > > > PRAGMA journal_mode=WAL > > > > > _______________________________________________ > > > > > sqlite-users mailing list > > > > > [email protected] > > > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > > > > > > > > > > > > > > > -- > > > > D. Richard Hipp > > > > [email protected] > > > > _______________________________________________ > > > > sqlite-users mailing list > > > > [email protected] > > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > _______________________________________________ > > > sqlite-users mailing list > > > [email protected] > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > > > > > -- > > D. Richard Hipp > > [email protected] > > _______________________________________________ > > sqlite-users mailing list > > [email protected] > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
