Re: [sqlite] 3.7.4 possible restore bug
On Thu, Dec 23, 2010 at 3:10 PM, Max Vlasov max.vla...@gmail.com wrote: Hi, I experimented with artificial power loss (using hd box) and 3.7.4 both library and shell didn't restore the files to the initial state. 3.6.10 restores successfully. This is a kind of repost, there wasn't any answer for my initial one. Please let me know is this bug or not a bug, I can't sleep without knowing the truth :) Steps to reproduce without additional test data 1. download windows shell 3.7.4 binary 2. sqlite testdb CREATE TABLE [TableOne] ([VALUE] INTEGER); .quit 3. sqlite testdb BEGIN TRANSACTION; INSERT INTO TableOne (Value) VALUES (123); 4. while still running the shell, unexpectedly interrupt the executable with some external tools (task manager for example) after this there's a file called testdb-journal near testdb 5. sqlite testdb .quit The result: testdb-journal is still there. Expected result: the journal file should be deleted by sqlite. Max Vlasov ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.7.4 possible restore bug
Hi, 12/01/2011 12:27, Max Vlasov wrote: On Thu, Dec 23, 2010 at 3:10 PM, Max Vlasovmax.vla...@gmail.com wrote: Hi, I experimented with artificial power loss (using hd box) and 3.7.4 both library and shell didn't restore the files to the initial state. 3.6.10 restores successfully. This is a kind of repost, there wasn't any answer for my initial one. Please let me know is this bug or not a bug, I can't sleep without knowing the truth :) Steps to reproduce without additional test data [snip] 3.7.2 behaves identically. Before quitting: - select shows nothing - inserting another record removes journal Max Vlasov -- Regards, Hakki Dogusan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.7.4 possible restore bug
On Wed, Jan 12, 2011 at 5:27 AM, Max Vlasov max.vla...@gmail.com wrote: On Thu, Dec 23, 2010 at 3:10 PM, Max Vlasov max.vla...@gmail.com wrote: Hi, I experimented with artificial power loss (using hd box) and 3.7.4 both library and shell didn't restore the files to the initial state. 3.6.10 restores successfully. This is a kind of repost, there wasn't any answer for my initial one. Please let me know is this bug or not a bug, I can't sleep without knowing the truth :) I suppose it would be a nice-to-have if SQLite were more aggressive about deleting stale journal files. But it is not a serious problem. There is no danger of database corruption here, or anything like that. The journal file is stale. It is not a hot journal. And it won't (and can't) be rolled back. It's just a junk file that got left around. It will get cleaned up on the next write transaction. I guess you are asking for an enhancement for it to be cleaned up on the next read transaction. So even though this is not currently a problem, fixing it might create real corruptions issues. The deletion of a journal files need to be done with extreme caution, lest they be deleted when they is still hot and hence cause database corruption. It will take us a lot of study and testing to verify that the deletion is safe. So this is not a simple fix. Steps to reproduce without additional test data 1. download windows shell 3.7.4 binary 2. sqlite testdb CREATE TABLE [TableOne] ([VALUE] INTEGER); .quit 3. sqlite testdb BEGIN TRANSACTION; INSERT INTO TableOne (Value) VALUES (123); 4. while still running the shell, unexpectedly interrupt the executable with some external tools (task manager for example) after this there's a file called testdb-journal near testdb 5. sqlite testdb .quit The result: testdb-journal is still there. Expected result: the journal file should be deleted by sqlite. Max Vlasov ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.7.4 possible restore bug
On Wed, Jan 12, 2011 at 3:48 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Jan 12, 2011 at 5:27 AM, Max Vlasov max.vla...@gmail.com wrote: On Thu, Dec 23, 2010 at 3:10 PM, Max Vlasov max.vla...@gmail.com wrote: Hi, I experimented with artificial power loss (using hd box) and 3.7.4 both library and shell didn't restore the files to the initial state. 3.6.10 restores successfully. This is a kind of repost, there wasn't any answer for my initial one. Please let me know is this bug or not a bug, I can't sleep without knowing the truth :) The journal file is stale. It is not a hot journal. And it won't (and can't) be rolled back. It's just a junk file that got left around. It will get cleaned up on the next write transaction. I guess you are asking for an enhancement for it to be cleaned up on the next read transaction. Richard, thanks for the clarification, it was just a little strange that previous versions (at least 3.6.10 I mentioned) deletes the same journal file upon simple opening (no writing) so possibly something was introduced after that made things a little more complex as you described. Also generally speaking the presence of -journal always was a kind of visual indication that either a write operation in progress (if connection is live) or something ended unexpectedly on previous session (if it's closed), but it appears that currently even several read-only sessions after that can keep this file around for a long period of time and this logic no longer works. Anyway I can live with that (and also sleep:) Thanks Max Vlasov ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] 3.7.4 possible restore bug
Hi, I experimented with artificial power loss (using hd box) and 3.7.4 both library and shell didn't restore the files to the initial state. 3.6.10 restores successfully. I don't know whether it's related the the contents of the file, but here the db files: www.maxerist.net/downloads/dbwithjournal.zip The steps to reproduce: unzip both files anywhere, open the db in sqlite shell (3.7.4), do the .quit and both the db and journal are still there. Max Vlasov ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] 3.7.4 possible restore bug
On Thu, Dec 23, 2010 at 3:10 PM, Max Vlasov max.vla...@gmail.com wrote: Hi, I experimented with artificial power loss (using hd box) and 3.7.4 both library and shell didn't restore the files to the initial state. 3.6.10 restores successfully. I don't know whether it's related the the contents of the file, but here the db files: http://www.maxerist.net/downloads/dbwithjournal.zip I did additional tests without power loss (just by killing the process). The result is the same (both the db and journal still exist) only when no single change is written to the db file (the original db and the db after the interruption are binary the same) and because of this it seems that the only problem is that the journal file is not deleted. If there was a real write to the db file, the restoration deletes the journal Max ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
