Hi, It's clear that for the WAL to be a general purpose solution, which can be used in systems which have constant stream of reads/writes from sqlite, it should not grow limitlessly under all circumstances (assuming the user run a checkpoint every once in a while).
I think my design can work (or at lease is a good start - and should be refined more), but I can't implement it, since I do not have a deep and profound enough knowledge in sqlite code and specifically in WAL format and behavior. I will try to implement a much simpler solution, which have many limitations (e.g. might work only with single process system), but solve the problem to me. the idea is to keep the last transaction in memory, and not writing it to the wal, until the commit. this will increase the chances that the checkpoint in the background can finish copy all the pages to the DB, so next write will be at the start of the file. This is good enough for me since: 1. I do not have logical transactions. I only use them to make writes faster, and I commit the transactions when sqlite cache is stressed, so they wont be very large. 1. I do not care about loosing the last transactions (in case of a crash). 3. My application is single process (multithreaded). If it will be interesting for someone, I will be happy to post a patch of this simpler solution. I hope to see a progress in this issue, and I am sure it will make sqlite more robust and thus more usable in a lot of situation. Yoni. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
