There is another reader but sharing the same connection. So checkpoint process cannot be blocked by another reader.
On Thu, Dec 1, 2011 at 8:54 PM, Yves Goergen <nospam.l...@unclassified.de>wrote: > On 01.12.2011 18:58 CE(S)T, Sreekumar TP wrote: > > During the measurement of manual checkpoint times, I see the following > > behaviour - > > > > # of WAL frames checkpointed is over 1000 > > size of DB has not changed after checkpoint.(measured using fstat) > > Time for the checkpoint if around 500 ms. > > > > Why is it that eventhough 1000+ frames are checkpointed, the DB size has > > not increased ? > > All records inserted are new and unique records and insertions start from > > empty database. > > Could it be that the pages were not actually written to the database > because there was a reader lock on them? Did any other process access > the database (and thus hold any locks) while you did the checkpointing? > > (Wild guess. I've only learned about WAL and started using it yesterday. > I've read the whole WAL documentation page [1] though.) > > [1] http://sqlite.org/wal.html > > -- > Yves Goergen "LonelyPixel" <nospam.l...@unclassified.de> > Visit my web laboratory at http://beta.unclassified.de > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
