Richard Hipp wrote: > On Tue, Nov 8, 2011 at 10:04 AM, Orit Alul <orit.a...@mediamind.com> wrote: > >> Hi, >> >> I've performed a vacuuming operation (I ran the following command: >> sqlite3.exe <dbName> VACUUM;). >> It caused the WAL file to be the same size as the db file and it never >> shrink back. >> >> For example I had a db file in the size of 1.8GB, wal file in the size of >> 1.7MB, shm file in the size of 32KB. >> I ran the VACUUM; command on the db file, now the db file got down to >> 1.2GB, wal file got up to 1.2GB and the shm file got up to 9.5MB. >> >> Do you have a clue what is the cause for this strange behavior? Do you >> know if there's a command that can shrink the files back? >> > > The WAL file is not truncated (prior to the last database connection > closing) because overwriting an existing file is faster than appending to a > file. Hence reusing an existing WAL is faster than truncating and > appending. > > But if the file is larger than you like, you can set an upper bound on its > size using the journal_size_limit pragma. > http://www.sqlite.org/pragma.html#pragma_journal_size_limit With this > pragma setting, the WAL will be truncated down to the requested size after > each successful checkpoint operation.
IMO, that should be mentioned in documentation. Currently it says this pragma affects only journal_mode=persist and locking_mode=exclusive. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
