Re: [sqlite] capturing and testing a hot journal
-Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of mm.w Sent: Tuesday, July 15, 2014 8:34 PM To: R Smith Cc: General Discussion of SQLite Database Subject: Re: [sqlite] capturing and testing a hot journal and I stay public even it looks weird, but seriously grew up and fast kiddo. As someone who is new to this thread aside from reading, could you please just stop unless you have something useful to say? I honestly can't tell by most of your comments whether you're a professional programmer or a high school whiner pretending to be something else, and it's pretty sad that it often takes you multiple emails to finish one thought because apparently you have no reasonable control over whatever mechanism you're using to post to this list. I don't appreciate your spam and I'm pretty sure no one else that receives individual emails from this list does either. If you can't stay on topic, don't participate in the topic at all. That being said, enjoy this, flame it and don't expect a response, because I don't want to be any more hypocritical than I already am by posting this in the first place. Eric ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
On 15 Jul 2014, at 2:20am, William Drago wdr...@suffolk.lib.ny.us wrote: The software doesn't crash on its own; I'm forcing it to crash with a divide-by-zero for test purposes. This doesn't happen in actual use and there's no reason other than a power failure for a transaction to not commit successfully. But that doesn't mean I shouldn't handle a failed transaction if it ever does happen. If all you're trying to do is spot crashes then you don't have to implement your own semaphore system or locking system. Use PRAGMA journal_mode = DELETE which is the default. Then you know that if a journal file exists, a process is in the middle of a transaction, or a process which in the middle of a transaction crashed. All you need to do is check to see if a file exists with the name of the journal file. Presumably you'd be wanting to do this when your application starts up, before it opens the database. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
ok sorry, I did not red all thru, may you simply sha1 local and remote ? if != commit again On Tue, Jul 15, 2014 at 12:49 AM, Simon Slavin slav...@bigfraud.org wrote: On 15 Jul 2014, at 2:20am, William Drago wdr...@suffolk.lib.ny.us wrote: The software doesn't crash on its own; I'm forcing it to crash with a divide-by-zero for test purposes. This doesn't happen in actual use and there's no reason other than a power failure for a transaction to not commit successfully. But that doesn't mean I shouldn't handle a failed transaction if it ever does happen. If all you're trying to do is spot crashes then you don't have to implement your own semaphore system or locking system. Use PRAGMA journal_mode = DELETE which is the default. Then you know that if a journal file exists, a process is in the middle of a transaction, or a process which in the middle of a transaction crashed. All you need to do is check to see if a file exists with the name of the journal file. Presumably you'd be wanting to do this when your application starts up, before it opens the database. Simon. ___ 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
Re: [sqlite] capturing and testing a hot journal
yes indeed the journal tweaking would work solely for this special file case, comparing local and remote that's how for instance git works like many other sync software, I don't know the API but is the box thing notify you on start transaction then on close, if not it sucks ? On Tue, Jul 15, 2014 at 6:53 AM, mm.w 0xcafef...@gmail.com wrote: ok sorry, I did not red all thru, may you simply sha1 local and remote ? if != commit again On Tue, Jul 15, 2014 at 12:49 AM, Simon Slavin slav...@bigfraud.org wrote: On 15 Jul 2014, at 2:20am, William Drago wdr...@suffolk.lib.ny.us wrote: The software doesn't crash on its own; I'm forcing it to crash with a divide-by-zero for test purposes. This doesn't happen in actual use and there's no reason other than a power failure for a transaction to not commit successfully. But that doesn't mean I shouldn't handle a failed transaction if it ever does happen. If all you're trying to do is spot crashes then you don't have to implement your own semaphore system or locking system. Use PRAGMA journal_mode = DELETE which is the default. Then you know that if a journal file exists, a process is in the middle of a transaction, or a process which in the middle of a transaction crashed. All you need to do is check to see if a file exists with the name of the journal file. Presumably you'd be wanting to do this when your application starts up, before it opens the database. Simon. ___ 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
Re: [sqlite] capturing and testing a hot journal
forgot if != commit again or restore if local unusable (lossy scenario) On Tue, Jul 15, 2014 at 7:01 AM, mm.w 0xcafef...@gmail.com wrote: yes indeed the journal tweaking would work solely for this special file case, comparing local and remote that's how for instance git works like many other sync software, I don't know the API but is the box thing notify you on start transaction then on close, if not it sucks ? On Tue, Jul 15, 2014 at 6:53 AM, mm.w 0xcafef...@gmail.com wrote: ok sorry, I did not red all thru, may you simply sha1 local and remote ? if != commit again On Tue, Jul 15, 2014 at 12:49 AM, Simon Slavin slav...@bigfraud.org wrote: On 15 Jul 2014, at 2:20am, William Drago wdr...@suffolk.lib.ny.us wrote: The software doesn't crash on its own; I'm forcing it to crash with a divide-by-zero for test purposes. This doesn't happen in actual use and there's no reason other than a power failure for a transaction to not commit successfully. But that doesn't mean I shouldn't handle a failed transaction if it ever does happen. If all you're trying to do is spot crashes then you don't have to implement your own semaphore system or locking system. Use PRAGMA journal_mode = DELETE which is the default. Then you know that if a journal file exists, a process is in the middle of a transaction, or a process which in the middle of a transaction crashed. All you need to do is check to see if a file exists with the name of the journal file. Presumably you'd be wanting to do this when your application starts up, before it opens the database. Simon. ___ 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
Re: [sqlite] capturing and testing a hot journal
On 15 Jul 2014, at 2:53pm, mm.w 0xcafef...@gmail.com wrote: ok sorry, I did not red all thru, may you simply sha1 local and remote ? if != commit again You won't have anything to commit. If your application really had crashed it wouldn't have any transaction data to commit. If your application had not crashed the transaction would always have worked. Anything that might sync a file automatically can make a mistake like this: 1) computer A and computer B both have local copies of the database open 2) users of computer A and computer B both make changes to their local copies 3) computer A and computer B both close their local copies Now the automatic syncing routine kicks in and notices that both copies have been modified since the last sync. Whichever copy it chooses, the changes made to the other copy are still going to be lost. Also, since the sync process doesn't understand that the journal file is intimately related to the database file, it can notice one file was updated and copy that across to another computer, and leave the other file as it was. While SQLite will notice that the two files don't match, and will not corrupt its database by trying to update it with the wrong journal, there's no way to tell whether you are going to get the data before the last transaction was committed or after. My recommendation to the OP is not to do any programming around this at all, since whatever programming you come up with will not be dependable. The routines for checking unexpected journal files in SQLite are very clever. Just leave SQLite to sort out rare crashes by itself, which it does pretty well. If, on the other hand, crashes aren't rare then I agree with the other poster to this thread who said that time is better spent diagnosing the cause of your crashes. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
Simon your design-idea do not reflect any reality, this is weak, there is a lack of experience on the topic and we can feel it. You won't have anything to commit. If your application really had crashed it wouldn't have any transaction data to commit. If your application had not crashed the transaction would always have worked. nope you can have a partial upload, a broken socket pipe et cetera, and you only assume a version of the file is not already remote and assume that after crash you might be able to recover local anyway. there are two scenario to check: local = remote after any network transaction local = remote after incident: + if not remote, test integrity of local + if remote make sure both are safe + if only remote restore/force sync has you got an interrupt (it happens with box) 1- the network flow could be interrupted no need a power failure for that to happen, it can happen that's you face also the case of undetected broken pipe, that's the reason you need to be notify by the network pooler API you use, 2- the journal tweaking only concern sqlite file and specific to it, then wrong design, make it work for anything using the common regular system of hashing/signing local to remote to ensure the integrity of the data, at least that's the only purpose of this discussion how I am sure whatever happen that I have my data in good shape somewhere. On Tue, Jul 15, 2014 at 9:16 AM, Simon Slavin slav...@bigfraud.org wrote: On 15 Jul 2014, at 2:53pm, mm.w 0xcafef...@gmail.com wrote: ok sorry, I did not red all thru, may you simply sha1 local and remote ? if != commit again You won't have anything to commit. If your application really had crashed it wouldn't have any transaction data to commit. If your application had not crashed the transaction would always have worked. Anything that might sync a file automatically can make a mistake like this: 1) computer A and computer B both have local copies of the database open 2) users of computer A and computer B both make changes to their local copies 3) computer A and computer B both close their local copies Now the automatic syncing routine kicks in and notices that both copies have been modified since the last sync. Whichever copy it chooses, the changes made to the other copy are still going to be lost. Also, since the sync process doesn't understand that the journal file is intimately related to the database file, it can notice one file was updated and copy that across to another computer, and leave the other file as it was. While SQLite will notice that the two files don't match, and will not corrupt its database by trying to update it with the wrong journal, there's no way to tell whether you are going to get the data before the last transaction was committed or after. My recommendation to the OP is not to do any programming around this at all, since whatever programming you come up with will not be dependable. The routines for checking unexpected journal files in SQLite are very clever. Just leave SQLite to sort out rare crashes by itself, which it does pretty well. If, on the other hand, crashes aren't rare then I agree with the other poster to this thread who said that time is better spent diagnosing the cause of your crashes. Simon. ___ 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
Re: [sqlite] capturing and testing a hot journal
but it does not imply that in rare cases that either of files are not busted, that's the reason of backups being able to recover last seen (the lossy case, shit happens) On Tue, Jul 15, 2014 at 10:06 AM, mm.w 0xcafef...@gmail.com wrote: Simon your design-idea do not reflect any reality, this is weak, there is a lack of experience on the topic and we can feel it. You won't have anything to commit. If your application really had crashed it wouldn't have any transaction data to commit. If your application had not crashed the transaction would always have worked. nope you can have a partial upload, a broken socket pipe et cetera, and you only assume a version of the file is not already remote and assume that after crash you might be able to recover local anyway. there are two scenario to check: local = remote after any network transaction local = remote after incident: + if not remote, test integrity of local + if remote make sure both are safe + if only remote restore/force sync has you got an interrupt (it happens with box) 1- the network flow could be interrupted no need a power failure for that to happen, it can happen that's you face also the case of undetected broken pipe, that's the reason you need to be notify by the network pooler API you use, 2- the journal tweaking only concern sqlite file and specific to it, then wrong design, make it work for anything using the common regular system of hashing/signing local to remote to ensure the integrity of the data, at least that's the only purpose of this discussion how I am sure whatever happen that I have my data in good shape somewhere. On Tue, Jul 15, 2014 at 9:16 AM, Simon Slavin slav...@bigfraud.org wrote: On 15 Jul 2014, at 2:53pm, mm.w 0xcafef...@gmail.com wrote: ok sorry, I did not red all thru, may you simply sha1 local and remote ? if != commit again You won't have anything to commit. If your application really had crashed it wouldn't have any transaction data to commit. If your application had not crashed the transaction would always have worked. Anything that might sync a file automatically can make a mistake like this: 1) computer A and computer B both have local copies of the database open 2) users of computer A and computer B both make changes to their local copies 3) computer A and computer B both close their local copies Now the automatic syncing routine kicks in and notices that both copies have been modified since the last sync. Whichever copy it chooses, the changes made to the other copy are still going to be lost. Also, since the sync process doesn't understand that the journal file is intimately related to the database file, it can notice one file was updated and copy that across to another computer, and leave the other file as it was. While SQLite will notice that the two files don't match, and will not corrupt its database by trying to update it with the wrong journal, there's no way to tell whether you are going to get the data before the last transaction was committed or after. My recommendation to the OP is not to do any programming around this at all, since whatever programming you come up with will not be dependable. The routines for checking unexpected journal files in SQLite are very clever. Just leave SQLite to sort out rare crashes by itself, which it does pretty well. If, on the other hand, crashes aren't rare then I agree with the other poster to this thread who said that time is better spent diagnosing the cause of your crashes. Simon. ___ 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
Re: [sqlite] capturing and testing a hot journal
On 2014/07/15 19:06, mm.w wrote: Simon your design-idea do not reflect any reality, this is weak, there is a lack of experience on the topic and we can feel it. Strange, I feel nothing of the sort and the only weak thing I can see involves the correlation between the computer and social skill sets you wield. Maybe you had a very different use-case in mind than what is normal for SQLite? - which is of course allowed. You won't have anything to commit. If your application really had crashed it wouldn't have any transaction data to commit. If your application had not crashed the transaction would always have worked. nope you can have a partial upload, a broken socket pipe et cetera, and you only assume a version of the file is not already remote and assume that after crash you might be able to recover local anyway. Partial uploads... broken pipes... these are all networking related issues and has nothing to do with file commitment of any SQLite code. When you make a server-client system which upload a stream or download it, or in any way sends it somewhere or manages synchronicity, it is the responsibility of either the client or the server to commit those databits to disk, not the pipe's responsibility. If the pipe dies halfway then the app would know it, and no amount of half-commits can happen. The only time SQLite engine can break a file by not completing a commit is if the program itself crashes or the physical media errors out, just like Simon said - none of which involve programmed-logic solutions. Report error and die - this is the way the Force guides us. there are two scenario to check: local = remote after any network transaction local = remote after incident: + if not remote, test integrity of local + if remote make sure both are safe + if only remote restore/force sync has you got an interrupt (it happens with box) 1- the network flow could be interrupted no need a power failure for that to happen, it can happen that's you face also the case of undetected broken pipe, that's the reason you need to be notify by the network pooler API you use, 2- the journal tweaking only concern sqlite file and specific to it, then wrong design, make it work for anything using the common regular system of hashing/signing local to remote to ensure the integrity of the data, at least that's the only purpose of this discussion how I am sure whatever happen that I have my data in good shape somewhere. This is establishing whether a file-transfer between some syncing services is successful and current, it has not a single thing to do with SQLite's ability to commit changes to the file or judging the need for roll-back. When SQLite starts the file is either broken or not, end of. This should be checked on a high level and has no bearing on anything to do with SQLite. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
yes that's exactly what I said thank you to confirm my dear 8) If the pipe dies halfway then the app would know it sorry LOL On Tue, Jul 15, 2014 at 12:13 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/15 19:06, mm.w wrote: Simon your design-idea do not reflect any reality, this is weak, there is a lack of experience on the topic and we can feel it. Strange, I feel nothing of the sort and the only weak thing I can see involves the correlation between the computer and social skill sets you wield. Maybe you had a very different use-case in mind than what is normal for SQLite? - which is of course allowed. You won't have anything to commit. If your application really had crashed it wouldn't have any transaction data to commit. If your application had not crashed the transaction would always have worked. nope you can have a partial upload, a broken socket pipe et cetera, and you only assume a version of the file is not already remote and assume that after crash you might be able to recover local anyway. Partial uploads... broken pipes... these are all networking related issues and has nothing to do with file commitment of any SQLite code. When you make a server-client system which upload a stream or download it, or in any way sends it somewhere or manages synchronicity, it is the responsibility of either the client or the server to commit those databits to disk, not the pipe's responsibility. If the pipe dies halfway then the app would know it, and no amount of half-commits can happen. The only time SQLite engine can break a file by not completing a commit is if the program itself crashes or the physical media errors out, just like Simon said - none of which involve programmed-logic solutions. Report error and die - this is the way the Force guides us. there are two scenario to check: local = remote after any network transaction local = remote after incident: + if not remote, test integrity of local + if remote make sure both are safe + if only remote restore/force sync has you got an interrupt (it happens with box) 1- the network flow could be interrupted no need a power failure for that to happen, it can happen that's you face also the case of undetected broken pipe, that's the reason you need to be notify by the network pooler API you use, 2- the journal tweaking only concern sqlite file and specific to it, then wrong design, make it work for anything using the common regular system of hashing/signing local to remote to ensure the integrity of the data, at least that's the only purpose of this discussion how I am sure whatever happen that I have my data in good shape somewhere. This is establishing whether a file-transfer between some syncing services is successful and current, it has not a single thing to do with SQLite's ability to commit changes to the file or judging the need for roll-back. When SQLite starts the file is either broken or not, end of. This should be checked on a high level and has no bearing on anything to do with SQLite. ___ 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
Re: [sqlite] capturing and testing a hot journal
to be clear, the original solution does not answer the question, it tries to relay on sqlite specifics, where specifics are beyond the sqlite small world. you must read back the first request to understand. On Tue, Jul 15, 2014 at 1:10 PM, mm.w 0xcafef...@gmail.com wrote: yes that's exactly what I said thank you to confirm my dear 8) If the pipe dies halfway then the app would know it sorry LOL On Tue, Jul 15, 2014 at 12:13 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/15 19:06, mm.w wrote: Simon your design-idea do not reflect any reality, this is weak, there is a lack of experience on the topic and we can feel it. Strange, I feel nothing of the sort and the only weak thing I can see involves the correlation between the computer and social skill sets you wield. Maybe you had a very different use-case in mind than what is normal for SQLite? - which is of course allowed. You won't have anything to commit. If your application really had crashed it wouldn't have any transaction data to commit. If your application had not crashed the transaction would always have worked. nope you can have a partial upload, a broken socket pipe et cetera, and you only assume a version of the file is not already remote and assume that after crash you might be able to recover local anyway. Partial uploads... broken pipes... these are all networking related issues and has nothing to do with file commitment of any SQLite code. When you make a server-client system which upload a stream or download it, or in any way sends it somewhere or manages synchronicity, it is the responsibility of either the client or the server to commit those databits to disk, not the pipe's responsibility. If the pipe dies halfway then the app would know it, and no amount of half-commits can happen. The only time SQLite engine can break a file by not completing a commit is if the program itself crashes or the physical media errors out, just like Simon said - none of which involve programmed-logic solutions. Report error and die - this is the way the Force guides us. there are two scenario to check: local = remote after any network transaction local = remote after incident: + if not remote, test integrity of local + if remote make sure both are safe + if only remote restore/force sync has you got an interrupt (it happens with box) 1- the network flow could be interrupted no need a power failure for that to happen, it can happen that's you face also the case of undetected broken pipe, that's the reason you need to be notify by the network pooler API you use, 2- the journal tweaking only concern sqlite file and specific to it, then wrong design, make it work for anything using the common regular system of hashing/signing local to remote to ensure the integrity of the data, at least that's the only purpose of this discussion how I am sure whatever happen that I have my data in good shape somewhere. This is establishing whether a file-transfer between some syncing services is successful and current, it has not a single thing to do with SQLite's ability to commit changes to the file or judging the need for roll-back. When SQLite starts the file is either broken or not, end of. This should be checked on a high level and has no bearing on anything to do with SQLite. ___ 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
Re: [sqlite] capturing and testing a hot journal
morality good question, wrong solution from the op + wrong solution gain of simon to endorse the bad design, so then when you are serious you roll-back to the entry point not the broken branch. On Tue, Jul 15, 2014 at 1:12 PM, mm.w 0xcafef...@gmail.com wrote: to be clear, the original solution does not answer the question, it tries to relay on sqlite specifics, where specifics are beyond the sqlite small world. you must read back the first request to understand. On Tue, Jul 15, 2014 at 1:10 PM, mm.w 0xcafef...@gmail.com wrote: yes that's exactly what I said thank you to confirm my dear 8) If the pipe dies halfway then the app would know it sorry LOL On Tue, Jul 15, 2014 at 12:13 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/15 19:06, mm.w wrote: Simon your design-idea do not reflect any reality, this is weak, there is a lack of experience on the topic and we can feel it. Strange, I feel nothing of the sort and the only weak thing I can see involves the correlation between the computer and social skill sets you wield. Maybe you had a very different use-case in mind than what is normal for SQLite? - which is of course allowed. You won't have anything to commit. If your application really had crashed it wouldn't have any transaction data to commit. If your application had not crashed the transaction would always have worked. nope you can have a partial upload, a broken socket pipe et cetera, and you only assume a version of the file is not already remote and assume that after crash you might be able to recover local anyway. Partial uploads... broken pipes... these are all networking related issues and has nothing to do with file commitment of any SQLite code. When you make a server-client system which upload a stream or download it, or in any way sends it somewhere or manages synchronicity, it is the responsibility of either the client or the server to commit those databits to disk, not the pipe's responsibility. If the pipe dies halfway then the app would know it, and no amount of half-commits can happen. The only time SQLite engine can break a file by not completing a commit is if the program itself crashes or the physical media errors out, just like Simon said - none of which involve programmed-logic solutions. Report error and die - this is the way the Force guides us. there are two scenario to check: local = remote after any network transaction local = remote after incident: + if not remote, test integrity of local + if remote make sure both are safe + if only remote restore/force sync has you got an interrupt (it happens with box) 1- the network flow could be interrupted no need a power failure for that to happen, it can happen that's you face also the case of undetected broken pipe, that's the reason you need to be notify by the network pooler API you use, 2- the journal tweaking only concern sqlite file and specific to it, then wrong design, make it work for anything using the common regular system of hashing/signing local to remote to ensure the integrity of the data, at least that's the only purpose of this discussion how I am sure whatever happen that I have my data in good shape somewhere. This is establishing whether a file-transfer between some syncing services is successful and current, it has not a single thing to do with SQLite's ability to commit changes to the file or judging the need for roll-back. When SQLite starts the file is either broken or not, end of. This should be checked on a high level and has no bearing on anything to do with SQLite. ___ 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
Re: [sqlite] capturing and testing a hot journal
sorry, I did not enter in the specifics of the answer, because it's driven by personal feelings which are off topic and surely misplaced but I will pass on this childish frustrations which are not my concern, bluntly I do not care, if you take that personally it's your problem, deal with it. thank you. On Tue, Jul 15, 2014 at 1:16 PM, mm.w 0xcafef...@gmail.com wrote: morality good question, wrong solution from the op + wrong solution gain of simon to endorse the bad design, so then when you are serious you roll-back to the entry point not the broken branch. On Tue, Jul 15, 2014 at 1:12 PM, mm.w 0xcafef...@gmail.com wrote: to be clear, the original solution does not answer the question, it tries to relay on sqlite specifics, where specifics are beyond the sqlite small world. you must read back the first request to understand. On Tue, Jul 15, 2014 at 1:10 PM, mm.w 0xcafef...@gmail.com wrote: yes that's exactly what I said thank you to confirm my dear 8) If the pipe dies halfway then the app would know it sorry LOL On Tue, Jul 15, 2014 at 12:13 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/15 19:06, mm.w wrote: Simon your design-idea do not reflect any reality, this is weak, there is a lack of experience on the topic and we can feel it. Strange, I feel nothing of the sort and the only weak thing I can see involves the correlation between the computer and social skill sets you wield. Maybe you had a very different use-case in mind than what is normal for SQLite? - which is of course allowed. You won't have anything to commit. If your application really had crashed it wouldn't have any transaction data to commit. If your application had not crashed the transaction would always have worked. nope you can have a partial upload, a broken socket pipe et cetera, and you only assume a version of the file is not already remote and assume that after crash you might be able to recover local anyway. Partial uploads... broken pipes... these are all networking related issues and has nothing to do with file commitment of any SQLite code. When you make a server-client system which upload a stream or download it, or in any way sends it somewhere or manages synchronicity, it is the responsibility of either the client or the server to commit those databits to disk, not the pipe's responsibility. If the pipe dies halfway then the app would know it, and no amount of half-commits can happen. The only time SQLite engine can break a file by not completing a commit is if the program itself crashes or the physical media errors out, just like Simon said - none of which involve programmed-logic solutions. Report error and die - this is the way the Force guides us. there are two scenario to check: local = remote after any network transaction local = remote after incident: + if not remote, test integrity of local + if remote make sure both are safe + if only remote restore/force sync has you got an interrupt (it happens with box) 1- the network flow could be interrupted no need a power failure for that to happen, it can happen that's you face also the case of undetected broken pipe, that's the reason you need to be notify by the network pooler API you use, 2- the journal tweaking only concern sqlite file and specific to it, then wrong design, make it work for anything using the common regular system of hashing/signing local to remote to ensure the integrity of the data, at least that's the only purpose of this discussion how I am sure whatever happen that I have my data in good shape somewhere. This is establishing whether a file-transfer between some syncing services is successful and current, it has not a single thing to do with SQLite's ability to commit changes to the file or judging the need for roll-back. When SQLite starts the file is either broken or not, end of. This should be checked on a high level and has no bearing on anything to do with SQLite. ___ 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
Re: [sqlite] capturing and testing a hot journal
to be clear, I am not a social worker but an engineer and never argue when I consider that's a lost cause, if you cannot straight talking 5 minutes in your life... don't ask me to say bravo, it's not big deal my little ducky when I think the contrary especially on a topic I know from the outside and the inside and all the possible entry point. thank you for getting back on earth. On Tue, Jul 15, 2014 at 1:27 PM, mm.w 0xcafef...@gmail.com wrote: sorry, I did not enter in the specifics of the answer, because it's driven by personal feelings which are off topic and surely misplaced but I will pass on this childish frustrations which are not my concern, bluntly I do not care, if you take that personally it's your problem, deal with it. thank you. On Tue, Jul 15, 2014 at 1:16 PM, mm.w 0xcafef...@gmail.com wrote: morality good question, wrong solution from the op + wrong solution gain of simon to endorse the bad design, so then when you are serious you roll-back to the entry point not the broken branch. On Tue, Jul 15, 2014 at 1:12 PM, mm.w 0xcafef...@gmail.com wrote: to be clear, the original solution does not answer the question, it tries to relay on sqlite specifics, where specifics are beyond the sqlite small world. you must read back the first request to understand. On Tue, Jul 15, 2014 at 1:10 PM, mm.w 0xcafef...@gmail.com wrote: yes that's exactly what I said thank you to confirm my dear 8) If the pipe dies halfway then the app would know it sorry LOL On Tue, Jul 15, 2014 at 12:13 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/15 19:06, mm.w wrote: Simon your design-idea do not reflect any reality, this is weak, there is a lack of experience on the topic and we can feel it. Strange, I feel nothing of the sort and the only weak thing I can see involves the correlation between the computer and social skill sets you wield. Maybe you had a very different use-case in mind than what is normal for SQLite? - which is of course allowed. You won't have anything to commit. If your application really had crashed it wouldn't have any transaction data to commit. If your application had not crashed the transaction would always have worked. nope you can have a partial upload, a broken socket pipe et cetera, and you only assume a version of the file is not already remote and assume that after crash you might be able to recover local anyway. Partial uploads... broken pipes... these are all networking related issues and has nothing to do with file commitment of any SQLite code. When you make a server-client system which upload a stream or download it, or in any way sends it somewhere or manages synchronicity, it is the responsibility of either the client or the server to commit those databits to disk, not the pipe's responsibility. If the pipe dies halfway then the app would know it, and no amount of half-commits can happen. The only time SQLite engine can break a file by not completing a commit is if the program itself crashes or the physical media errors out, just like Simon said - none of which involve programmed-logic solutions. Report error and die - this is the way the Force guides us. there are two scenario to check: local = remote after any network transaction local = remote after incident: + if not remote, test integrity of local + if remote make sure both are safe + if only remote restore/force sync has you got an interrupt (it happens with box) 1- the network flow could be interrupted no need a power failure for that to happen, it can happen that's you face also the case of undetected broken pipe, that's the reason you need to be notify by the network pooler API you use, 2- the journal tweaking only concern sqlite file and specific to it, then wrong design, make it work for anything using the common regular system of hashing/signing local to remote to ensure the integrity of the data, at least that's the only purpose of this discussion how I am sure whatever happen that I have my data in good shape somewhere. This is establishing whether a file-transfer between some syncing services is successful and current, it has not a single thing to do with SQLite's ability to commit changes to the file or judging the need for roll-back. When SQLite starts the file is either broken or not, end of. This should be checked on a high level and has no bearing on anything to do with SQLite. ___ 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
Re: [sqlite] capturing and testing a hot journal
On 2014/07/15 22:33, mm.w wrote: whine_spam++ // Apologies to all. Not sure if this is intended for Simon too, or only myself - either way, would you be so kind as to take it off-list, it is of no benefit to others here - much appreciated. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
why Apologies when it's solely addressed to you, please don't be a hypocrite everybody can understand that in your first paragraph you are out of the topic and the line. thank you, apology accepted... (SIK) On Tue, Jul 15, 2014 at 1:59 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/15 22:33, mm.w wrote: whine_spam++ // Apologies to all. Not sure if this is intended for Simon too, or only myself - either way, would you be so kind as to take it off-list, it is of no benefit to others here - much appreciated. ___ 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
Re: [sqlite] capturing and testing a hot journal
don't try to look good when you are not. thank you. On Tue, Jul 15, 2014 at 2:02 PM, mm.w 0xcafef...@gmail.com wrote: why Apologies when it's solely addressed to you, please don't be a hypocrite everybody can understand that in your first paragraph you are out of the topic and the line. thank you, apology accepted... (SIK) On Tue, Jul 15, 2014 at 1:59 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/15 22:33, mm.w wrote: whine_spam++ // Apologies to all. Not sure if this is intended for Simon too, or only myself - either way, would you be so kind as to take it off-list, it is of no benefit to others here - much appreciated. ___ 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
Re: [sqlite] capturing and testing a hot journal
And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you, no rocket science here when you are honest with yourself, but I can tell you, I will be the last guy here to burn you out personally, if you don't like arguing stop coding and Simon is enough solid to answer himself I don't think he is crying in the corner... he certainly does not need a baby-sister popping up with ridiculous statements thinking she is the queeny, sorry but this is ridiculous, anyone who lead team over 50 persons on tough projects means projecting yourself over a 2 years round, must laugh at large, I can't tell you, my little candy. Best. On Tue, Jul 15, 2014 at 2:04 PM, mm.w 0xcafef...@gmail.com wrote: don't try to look good when you are not. thank you. On Tue, Jul 15, 2014 at 2:02 PM, mm.w 0xcafef...@gmail.com wrote: why Apologies when it's solely addressed to you, please don't be a hypocrite everybody can understand that in your first paragraph you are out of the topic and the line. thank you, apology accepted... (SIK) On Tue, Jul 15, 2014 at 1:59 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/15 22:33, mm.w wrote: whine_spam++ // Apologies to all. Not sure if this is intended for Simon too, or only myself - either way, would you be so kind as to take it off-list, it is of no benefit to others here - much appreciated. ___ 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
Re: [sqlite] capturing and testing a hot journal
On 15 Jul 2014, at 11:03pm, mm.w 0xcafef...@gmail.com wrote: Simon is enough solid to answer himself Thank you. I don't think he is crying in the corner True. But if lots of people all post the same advice it can be more persuasive than one person posting the same thing again and again. So having make my statement I retire from the discussion. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
I agree I am not the best communication guy ever born but I can say no guys don't roll-back this is a terrible idea without getting personal On Tue, Jul 15, 2014 at 3:26 PM, Simon Slavin slav...@bigfraud.org wrote: On 15 Jul 2014, at 11:03pm, mm.w 0xcafef...@gmail.com wrote: Simon is enough solid to answer himself Thank you. I don't think he is crying in the corner True. But if lots of people all post the same advice it can be more persuasive than one person posting the same thing again and again. So having make my statement I retire from the discussion. Simon. ___ 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
Re: [sqlite] capturing and testing a hot journal
anyway no drama here, I am not here to fight or getting personal, that's just on a situation I ve seen I get passionate that's all On Tue, Jul 15, 2014 at 3:28 PM, mm.w 0xcafef...@gmail.com wrote: I agree I am not the best communication guy ever born but I can say no guys don't roll-back this is a terrible idea without getting personal On Tue, Jul 15, 2014 at 3:26 PM, Simon Slavin slav...@bigfraud.org wrote: On 15 Jul 2014, at 11:03pm, mm.w 0xcafef...@gmail.com wrote: Simon is enough solid to answer himself Thank you. I don't think he is crying in the corner True. But if lots of people all post the same advice it can be more persuasive than one person posting the same thing again and again. So having make my statement I retire from the discussion. Simon. ___ 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
Re: [sqlite] capturing and testing a hot journal
On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
seriously Rsmith \\\ 3 slashes is the microsoft guy way then I give a try 8D On Tue, Jul 15, 2014 at 4:48 PM, mm.w 0xcafef...@gmail.com wrote: I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
I am sorry I am jocking but you 'r calling of for white flag and use it to charge again. On Tue, Jul 15, 2014 at 4:51 PM, mm.w 0xcafef...@gmail.com wrote: seriously Rsmith \\\ 3 slashes is the microsoft guy way then I give a try 8D On Tue, Jul 15, 2014 at 4:48 PM, mm.w 0xcafef...@gmail.com wrote: I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
and moreover you bluntly lie On Tue, Jul 15, 2014 at 4:53 PM, mm.w 0xcafef...@gmail.com wrote: I am sorry I am jocking but you 'r calling of for white flag and use it to charge again. On Tue, Jul 15, 2014 at 4:51 PM, mm.w 0xcafef...@gmail.com wrote: seriously Rsmith \\\ 3 slashes is the microsoft guy way then I give a try 8D On Tue, Jul 15, 2014 at 4:48 PM, mm.w 0xcafef...@gmail.com wrote: I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
oh boy On Tue, Jul 15, 2014 at 5:10 PM, mm.w 0xcafef...@gmail.com wrote: and moreover you bluntly lie On Tue, Jul 15, 2014 at 4:53 PM, mm.w 0xcafef...@gmail.com wrote: I am sorry I am jocking but you 'r calling of for white flag and use it to charge again. On Tue, Jul 15, 2014 at 4:51 PM, mm.w 0xcafef...@gmail.com wrote: seriously Rsmith \\\ 3 slashes is the microsoft guy way then I give a try 8D On Tue, Jul 15, 2014 at 4:48 PM, mm.w 0xcafef...@gmail.com wrote: I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
I thought you were a good person... seriously? what it is your issue with just telling the truth, I am the first person here to say I am full of shit, sorry for the derogatory language but that's fact get back on your feet man! On Tue, Jul 15, 2014 at 5:11 PM, mm.w 0xcafef...@gmail.com wrote: oh boy On Tue, Jul 15, 2014 at 5:10 PM, mm.w 0xcafef...@gmail.com wrote: and moreover you bluntly lie On Tue, Jul 15, 2014 at 4:53 PM, mm.w 0xcafef...@gmail.com wrote: I am sorry I am jocking but you 'r calling of for white flag and use it to charge again. On Tue, Jul 15, 2014 at 4:51 PM, mm.w 0xcafef...@gmail.com wrote: seriously Rsmith \\\ 3 slashes is the microsoft guy way then I give a try 8D On Tue, Jul 15, 2014 at 4:48 PM, mm.w 0xcafef...@gmail.com wrote: I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
almost 2 hours of of unbelievable crap seriously? just for accusing me of bad behaviors towards Simon on a topic you don't even know? sorry again. On Tue, Jul 15, 2014 at 5:15 PM, mm.w 0xcafef...@gmail.com wrote: I thought you were a good person... seriously? what it is your issue with just telling the truth, I am the first person here to say I am full of shit, sorry for the derogatory language but that's fact get back on your feet man! On Tue, Jul 15, 2014 at 5:11 PM, mm.w 0xcafef...@gmail.com wrote: oh boy On Tue, Jul 15, 2014 at 5:10 PM, mm.w 0xcafef...@gmail.com wrote: and moreover you bluntly lie On Tue, Jul 15, 2014 at 4:53 PM, mm.w 0xcafef...@gmail.com wrote: I am sorry I am jocking but you 'r calling of for white flag and use it to charge again. On Tue, Jul 15, 2014 at 4:51 PM, mm.w 0xcafef...@gmail.com wrote: seriously Rsmith \\\ 3 slashes is the microsoft guy way then I give a try 8D On Tue, Jul 15, 2014 at 4:48 PM, mm.w 0xcafef...@gmail.com wrote: I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
yes where arethe social kills? telling crap loooking a like a queenie? just work on tv man not real life. On Tue, Jul 15, 2014 at 5:18 PM, mm.w 0xcafef...@gmail.com wrote: almost 2 hours of of unbelievable crap seriously? just for accusing me of bad behaviors towards Simon on a topic you don't even know? sorry again. On Tue, Jul 15, 2014 at 5:15 PM, mm.w 0xcafef...@gmail.com wrote: I thought you were a good person... seriously? what it is your issue with just telling the truth, I am the first person here to say I am full of shit, sorry for the derogatory language but that's fact get back on your feet man! On Tue, Jul 15, 2014 at 5:11 PM, mm.w 0xcafef...@gmail.com wrote: oh boy On Tue, Jul 15, 2014 at 5:10 PM, mm.w 0xcafef...@gmail.com wrote: and moreover you bluntly lie On Tue, Jul 15, 2014 at 4:53 PM, mm.w 0xcafef...@gmail.com wrote: I am sorry I am jocking but you 'r calling of for white flag and use it to charge again. On Tue, Jul 15, 2014 at 4:51 PM, mm.w 0xcafef...@gmail.com wrote: seriously Rsmith \\\ 3 slashes is the microsoft guy way then I give a try 8D On Tue, Jul 15, 2014 at 4:48 PM, mm.w 0xcafef...@gmail.com wrote: I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
and I stay public even it looks weird, but seriously grew up and fast kiddo. On Tue, Jul 15, 2014 at 5:21 PM, mm.w 0xcafef...@gmail.com wrote: yes where arethe social kills? telling crap loooking a like a queenie? just work on tv man not real life. On Tue, Jul 15, 2014 at 5:18 PM, mm.w 0xcafef...@gmail.com wrote: almost 2 hours of of unbelievable crap seriously? just for accusing me of bad behaviors towards Simon on a topic you don't even know? sorry again. On Tue, Jul 15, 2014 at 5:15 PM, mm.w 0xcafef...@gmail.com wrote: I thought you were a good person... seriously? what it is your issue with just telling the truth, I am the first person here to say I am full of shit, sorry for the derogatory language but that's fact get back on your feet man! On Tue, Jul 15, 2014 at 5:11 PM, mm.w 0xcafef...@gmail.com wrote: oh boy On Tue, Jul 15, 2014 at 5:10 PM, mm.w 0xcafef...@gmail.com wrote: and moreover you bluntly lie On Tue, Jul 15, 2014 at 4:53 PM, mm.w 0xcafef...@gmail.com wrote: I am sorry I am jocking but you 'r calling of for white flag and use it to charge again. On Tue, Jul 15, 2014 at 4:51 PM, mm.w 0xcafef...@gmail.com wrote: seriously Rsmith \\\ 3 slashes is the microsoft guy way then I give a try 8D On Tue, Jul 15, 2014 at 4:48 PM, mm.w 0xcafef...@gmail.com wrote: I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
You stay public even when it is annoying the entire list? I don't suppose a request to temporarily block him from the list would do any good, would it? May be time to investigate how to get gmail to block specific addresses. On Tue, Jul 15, 2014 at 6:34 PM, mm.w 0xcafef...@gmail.com wrote: and I stay public even it looks weird, but seriously grew up and fast kiddo. On Tue, Jul 15, 2014 at 5:21 PM, mm.w 0xcafef...@gmail.com wrote: yes where arethe social kills? telling crap loooking a like a queenie? just work on tv man not real life. On Tue, Jul 15, 2014 at 5:18 PM, mm.w 0xcafef...@gmail.com wrote: almost 2 hours of of unbelievable crap seriously? just for accusing me of bad behaviors towards Simon on a topic you don't even know? sorry again. On Tue, Jul 15, 2014 at 5:15 PM, mm.w 0xcafef...@gmail.com wrote: I thought you were a good person... seriously? what it is your issue with just telling the truth, I am the first person here to say I am full of shit, sorry for the derogatory language but that's fact get back on your feet man! On Tue, Jul 15, 2014 at 5:11 PM, mm.w 0xcafef...@gmail.com wrote: oh boy On Tue, Jul 15, 2014 at 5:10 PM, mm.w 0xcafef...@gmail.com wrote: and moreover you bluntly lie On Tue, Jul 15, 2014 at 4:53 PM, mm.w 0xcafef...@gmail.com wrote: I am sorry I am jocking but you 'r calling of for white flag and use it to charge again. On Tue, Jul 15, 2014 at 4:51 PM, mm.w 0xcafef...@gmail.com wrote: seriously Rsmith \\\ 3 slashes is the microsoft guy way then I give a try 8D On Tue, Jul 15, 2014 at 4:48 PM, mm.w 0xcafef...@gmail.com wrote: I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- Scott Robison ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
yes because I have nothing to hide, if you wish to block me so be it, no offense taken, do it and we can share a beer anytime. On Tue, Jul 15, 2014 at 5:35 PM, Scott Robison sc...@casaderobison.com wrote: You stay public even when it is annoying the entire list? I don't suppose a request to temporarily block him from the list would do any good, would it? May be time to investigate how to get gmail to block specific addresses. On Tue, Jul 15, 2014 at 6:34 PM, mm.w 0xcafef...@gmail.com wrote: and I stay public even it looks weird, but seriously grew up and fast kiddo. On Tue, Jul 15, 2014 at 5:21 PM, mm.w 0xcafef...@gmail.com wrote: yes where arethe social kills? telling crap loooking a like a queenie? just work on tv man not real life. On Tue, Jul 15, 2014 at 5:18 PM, mm.w 0xcafef...@gmail.com wrote: almost 2 hours of of unbelievable crap seriously? just for accusing me of bad behaviors towards Simon on a topic you don't even know? sorry again. On Tue, Jul 15, 2014 at 5:15 PM, mm.w 0xcafef...@gmail.com wrote: I thought you were a good person... seriously? what it is your issue with just telling the truth, I am the first person here to say I am full of shit, sorry for the derogatory language but that's fact get back on your feet man! On Tue, Jul 15, 2014 at 5:11 PM, mm.w 0xcafef...@gmail.com wrote: oh boy On Tue, Jul 15, 2014 at 5:10 PM, mm.w 0xcafef...@gmail.com wrote: and moreover you bluntly lie On Tue, Jul 15, 2014 at 4:53 PM, mm.w 0xcafef...@gmail.com wrote: I am sorry I am jocking but you 'r calling of for white flag and use it to charge again. On Tue, Jul 15, 2014 at 4:51 PM, mm.w 0xcafef...@gmail.com wrote: seriously Rsmith \\\ 3 slashes is the microsoft guy way then I give a try 8D On Tue, Jul 15, 2014 at 4:48 PM, mm.w 0xcafef...@gmail.com wrote: I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- Scott Robison ___ 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
Re: [sqlite] capturing and testing a hot journal
if you want some hint about google mail I can provide you, I could even ask for my username change without any loss On Tue, Jul 15, 2014 at 5:37 PM, mm.w 0xcafef...@gmail.com wrote: yes because I have nothing to hide, if you wish to block me so be it, no offense taken, do it and we can share a beer anytime. On Tue, Jul 15, 2014 at 5:35 PM, Scott Robison sc...@casaderobison.com wrote: You stay public even when it is annoying the entire list? I don't suppose a request to temporarily block him from the list would do any good, would it? May be time to investigate how to get gmail to block specific addresses. On Tue, Jul 15, 2014 at 6:34 PM, mm.w 0xcafef...@gmail.com wrote: and I stay public even it looks weird, but seriously grew up and fast kiddo. On Tue, Jul 15, 2014 at 5:21 PM, mm.w 0xcafef...@gmail.com wrote: yes where arethe social kills? telling crap loooking a like a queenie? just work on tv man not real life. On Tue, Jul 15, 2014 at 5:18 PM, mm.w 0xcafef...@gmail.com wrote: almost 2 hours of of unbelievable crap seriously? just for accusing me of bad behaviors towards Simon on a topic you don't even know? sorry again. On Tue, Jul 15, 2014 at 5:15 PM, mm.w 0xcafef...@gmail.com wrote: I thought you were a good person... seriously? what it is your issue with just telling the truth, I am the first person here to say I am full of shit, sorry for the derogatory language but that's fact get back on your feet man! On Tue, Jul 15, 2014 at 5:11 PM, mm.w 0xcafef...@gmail.com wrote: oh boy On Tue, Jul 15, 2014 at 5:10 PM, mm.w 0xcafef...@gmail.com wrote: and moreover you bluntly lie On Tue, Jul 15, 2014 at 4:53 PM, mm.w 0xcafef...@gmail.com wrote: I am sorry I am jocking but you 'r calling of for white flag and use it to charge again. On Tue, Jul 15, 2014 at 4:51 PM, mm.w 0xcafef...@gmail.com wrote: seriously Rsmith \\\ 3 slashes is the microsoft guy way then I give a try 8D On Tue, Jul 15, 2014 at 4:48 PM, mm.w 0xcafef...@gmail.com wrote: I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- Scott Robison ___ 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
Re: [sqlite] capturing and testing a hot journal
and yes I don't spit in a face of someone, then selling my so good reputation you are joke rsmith and you would dare any of the crap face to face sorry truth must be told and I did not started this shit for the record. On Tue, Jul 15, 2014 at 5:39 PM, mm.w 0xcafef...@gmail.com wrote: if you want some hint about google mail I can provide you, I could even ask for my username change without any loss On Tue, Jul 15, 2014 at 5:37 PM, mm.w 0xcafef...@gmail.com wrote: yes because I have nothing to hide, if you wish to block me so be it, no offense taken, do it and we can share a beer anytime. On Tue, Jul 15, 2014 at 5:35 PM, Scott Robison sc...@casaderobison.com wrote: You stay public even when it is annoying the entire list? I don't suppose a request to temporarily block him from the list would do any good, would it? May be time to investigate how to get gmail to block specific addresses. On Tue, Jul 15, 2014 at 6:34 PM, mm.w 0xcafef...@gmail.com wrote: and I stay public even it looks weird, but seriously grew up and fast kiddo. On Tue, Jul 15, 2014 at 5:21 PM, mm.w 0xcafef...@gmail.com wrote: yes where arethe social kills? telling crap loooking a like a queenie? just work on tv man not real life. On Tue, Jul 15, 2014 at 5:18 PM, mm.w 0xcafef...@gmail.com wrote: almost 2 hours of of unbelievable crap seriously? just for accusing me of bad behaviors towards Simon on a topic you don't even know? sorry again. On Tue, Jul 15, 2014 at 5:15 PM, mm.w 0xcafef...@gmail.com wrote: I thought you were a good person... seriously? what it is your issue with just telling the truth, I am the first person here to say I am full of shit, sorry for the derogatory language but that's fact get back on your feet man! On Tue, Jul 15, 2014 at 5:11 PM, mm.w 0xcafef...@gmail.com wrote: oh boy On Tue, Jul 15, 2014 at 5:10 PM, mm.w 0xcafef...@gmail.com wrote: and moreover you bluntly lie On Tue, Jul 15, 2014 at 4:53 PM, mm.w 0xcafef...@gmail.com wrote: I am sorry I am jocking but you 'r calling of for white flag and use it to charge again. On Tue, Jul 15, 2014 at 4:51 PM, mm.w 0xcafef...@gmail.com wrote: seriously Rsmith \\\ 3 slashes is the microsoft guy way then I give a try 8D On Tue, Jul 15, 2014 at 4:48 PM, mm.w 0xcafef...@gmail.com wrote: I already accepted your apologies why don't you give some air simply? instead of poisoning the actual lame situation? On Tue, Jul 15, 2014 at 4:46 PM, mm.w 0xcafef...@gmail.com wrote: am not else you don't understand one single line of my previous comments, you are just pissed off and not able to calling off thing I did On Tue, Jul 15, 2014 at 4:44 PM, mm.w 0xcafef...@gmail.com wrote: you dare to affirm that I affirm , I On Tue, Jul 15, 2014 at 4:43 PM, mm.w 0xcafef...@gmail.com wrote: hello, if you think so, I have noting to say to you, because you already made your judgement without giving a right of answer, so be it. On Tue, Jul 15, 2014 at 4:18 PM, RSmith rsm...@rsweb.co.za wrote: On 2014/07/16 00:03, mm.w wrote: And to finally be clear I am a plain guy I don't hide behind the curtain like you lamely try, that's public and solely addressed to you//.. I'd really like to not have another go at this thread, and again would like to apologise to the onlookers - but would like to affirm that this is not a personal feud that spilt onto the forum, I have to date not received a single mail from Mr. mm.w which did not also reach the list - contrary to the insinuation. I think he may simply be unaware he is/was posting to the list, for which I apologise too and ask to please give him the benefit of the doubt and excuse the thread. Mm.w, Sir, I guarantee you I have not a single hard feeling, we all have bad days, but please take this off-list hence. Thank you kindly Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- Scott Robison ___ 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
Re: [sqlite] capturing and testing a hot journal
mm.w wrote: Can someone please get this a*h*l* banned? -- Will ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
On Sun, 13 Jul 2014 18:00:59 +0100, Simon Slavin slav...@bigfraud.org wrote: On 12 Jul 2014, at 9:37am, Charles Parnot charles.par...@gmail.com wrote: - the journal file is actually not “hot” and I misunderstood the conditions that make it hot That one. The files on disk aren't 'hot' (as I think you mean it) while you're in a transaction. Your file system is not pushing journal changes at the file level. It doesn't need to do that while a transaction is open. since while the transaction is open, the database is locked so nothing else can use it anyway, and if your app crashes the whole transaction will be ignored. SQLite could be written to push transactions to the journal file on each change, but that would involve lots of writing to disk, so it would make SQLite slower, and for no gain. [snip] The test case I am generating is just for a simple edge case of our Dropbox-based syncing Yes, DropBox can be a problem for open SQLite databases. As a file level duplication system which does not understand locks, there's no good way to make DropBox work with open SQLite databases, or as a mediator for concurrent multi-user changes to a database. I had to explain to some users that a database change is not 'safe' until the database is closed. As far as I know, a database change is safe after a successfull COMMIT. Commit also releases locks. One thing that's worth testing is to make sure that recovery after crashes always yields a database with either pre- or post- transaction data rather than something corrupt which can't be opened. I don't know much about how DropBox works. Could it perhaps end up with a database file from one computer but journal file from another ? Indeed, or a journal file and a database file of different points in time. One could expect dropbox to respect locks, but it doesn't seem to do that. It also soesn't seem to synchronize a directory in an atomic fashion, which would be necessary to maintain consistency for sqlite or any other software that works on time-coordinated sets of files. In my opinion dropbox should not be used on directories with SQLite databases at all. It would be better to only allow dropbox access to directories with backups, and an application level synchronisation/recovery mechanism to reconstruct the main database from the backup when needed. -- Regards, Kees Nuyt ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
On 14 Jul 2014, at 11:19am, Kees Nuyt k.n...@zonnet.nl wrote: On Sun, 13 Jul 2014 18:00:59 +0100, Simon Slavin slav...@bigfraud.org wrote: I had to explain to some users that a database change is not 'safe' until the database is closed. As far as I know, a database change is safe after a successfull COMMIT. Commit also releases locks. That's what the documentation says, and it's a safe way to operate if all your access to the file is via one API. Unfortunately, the drivers for many storage media lie to the operating system and do not flush changes to disk when told to. On a test system running Windows 98, using a C program writing a text file, I was able to prove that doing all the locking and flushing the documentation required still did not properly update the file on disk. However, the file was always updated by a few seconds after the file was closed so I have used that as a yardstick ever since. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
On Mon, 14 Jul 2014 12:09:46 +0100, Simon Slavin slav...@bigfraud.org wrote: On 14 Jul 2014, at 11:19am, Kees Nuyt k.n...@zonnet.nl wrote: On Sun, 13 Jul 2014 18:00:59 +0100, Simon Slavin slav...@bigfraud.org wrote: I had to explain to some users that a database change is not 'safe' until the database is closed. As far as I know, a database change is safe after a successfull COMMIT. Commit also releases locks. That's what the documentation says, and it's a safe way to operate if all your access to the file is via one API. Unfortunately, the drivers for many storage media lie to the operating system and do not flush changes to disk when told to. On a test system running Windows 98, using a C program writing a text file, I was able to prove that doing all the locking and flushing the documentation required still did not properly update the file on disk. However, the file was always updated by a few seconds after the file was closed so I have used that as a yardstick ever since. Aha, I see. Yes, ill-behaving filesystems can do that. The question is whether experiences on Windows 98 are still relevant for rules of thumb in 2014. -- Regards, Kees Nuyt ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
On 14 Jul 2014, at 12:53pm, Kees Nuyt k.n...@zonnet.nl wrote: Aha, I see. Yes, ill-behaving filesystems can do that. The question is whether experiences on Windows 98 are still relevant for rules of thumb in 2014. I mentioned Windows 98 to let you know how out-of-date my text was. I no longer have a job which involves testing like that so I can't do an updated one. At least one of the things lying about updates was the hard disk driver. (Samsung, if I recall correctly, though I doubt any competing manufacturer was any better.) I bet they're still using more or less the same driver. This was, of course, a hard disk intended for use in a perfectly normal desktop computer, not for use in a server. By the way, anyone reading this who might want to know why everything lies: doing proper updates, and checking to make sure hardware has changed before software can move on slows down the operation of your computer /a lot/. For a dedicated server you might want it. For your desktop computer you really don't. I once set up server-class hardware with server-class hard disk with the jumper settings set to Yes, really wait for writes to happen before acknowledging it.. The computer took over 10 minutes to boot and another 10 minutes before I had Word loaded. Once it was running with a reasonable number of apps open, I think I managed to get almost three characters a second when typing a Word document. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
Am 14.07.2014 13:53, schrieb Kees Nuyt: On Mon, 14 Jul 2014 12:09:46 +0100, Simon Slavin slav...@bigfraud.org wrote: On 14 Jul 2014, at 11:19am, Kees Nuyt k.n...@zonnet.nl wrote: On Sun, 13 Jul 2014 18:00:59 +0100, Simon Slavin slav...@bigfraud.org wrote: I had to explain to some users that a database change is not 'safe' until the database is closed. As far as I know, a database change is safe after a successfull COMMIT. Commit also releases locks. That's what the documentation says, and it's a safe way to operate if all your access to the file is via one API. Unfortunately, the drivers for many storage media lie to the operating system and do not flush changes to disk when told to. On a test system running Windows 98, using a C program writing a text file, I was able to prove that doing all the locking and flushing the documentation required still did not properly update the file on disk. However, the file was always updated by a few seconds after the file was closed so I have used that as a yardstick ever since. Aha, I see. Yes, ill-behaving filesystems can do that. The question is whether experiences on Windows 98 are still relevant for rules of thumb in 2014. As most people probably keep the write caches on their hard drives 'ON', yes. If even your hardware lies in the name of performance, you should probably be a little paranoid. So it is not just filesystems, it is hardware too. So if you do a successful commit and the OS and hardware don't lie to you, your change is safe. But there are lies of varying magnitude at work. So if it is really important, wait a few minutes until the OS has surely flushed all its buffers and the HDDs did the same. Michael -- Michael Schlenker Software Architect CONTACT Software GmbH Tel.: +49 (421) 20153-80 Wiener Straße 1-3 Fax:+49 (421) 20153-41 28359 Bremen http://www.contact.de/ E-Mail: m...@contact.de Sitz der Gesellschaft: Bremen Geschäftsführer: Karl Heinz Zachries, Ralf Holtgrefe Eingetragen im Handelsregister des Amtsgerichts Bremen unter HRB 13215 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
This may be a bit simplistic, but it does give me a reasonable degree of confidence that hot journal files are being handled correctly in my application. I simply put a 1/0 on the line before my commit to purposely crash my app. Sure enough there's a journal file after the crash (I have a rather large transaction consisting of among other things, about 35 rows inserted, each containing a blob). When I restart my app it looks for the presence of a journal file and will open and read the db so that SQLite can deal with it. It also displays a message letting the user know that something went wrong during the last run. I do this with a test db of course, not the real one. -Bill -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- boun...@sqlite.org] On Behalf Of Charles Parnot Sent: Saturday, July 12, 2014 4:38 AM To: sqlite-users@sqlite.org Subject: [sqlite] capturing and testing a hot journal Hi all, For testing purposes of our application (a Mac app), I am generating what I thought would be a database with a hot journal using this approach (on an existing database): - open the database (and PRAGMA journal_mode = TRUNCATE;) - open a transaction: BEGIN IMMEDIATE TRANSACTION; - add some rows: INSERT etc... - **make a copy of the db and journal files** (while still hot?) - close the transaction Then I open the copied database+journal (naming the files appropriately), again in TRUNCATE journal mode. As expected, the content of the database does not include the inserted rows. However, the journal file is not emptied, even after closing the database. Based on the documentation (http://www.sqlite.org/lockingv3.html#hot_journals), I would have expected the journal file to be emptied because it is hot. There are 2 options here: - the journal file is actually not hot and I misunderstood the conditions that make it hot - there is a bug in SQLite Obviously, I strongly suspect I am misunderstanding things, and don't think it is an SQLite bug. Despite intensive Google-ing and more testing, I am not sure what makes the journal non-hot. Thanks for your help! Charles NB: You might be wondering why I am doing the above. I realize SQLite has already much more advanced tests for hot db+journals (running custom versions of filesystems to generate all kind of edge cases). The test case I am generating is just for a simple edge case of our Dropbox-based syncing (see: https://github.com/cparnot/PARStore and http://mjtsai.com/blog/2014/05/21/findings-1-0-and-parstore/). For a given database file, there is only one device that can write to it, all other devices being read-only (not in terms of filesystem, but sqlite- wise). But it is possible that Dropbox will copy a database and journal files that are not consistent with each other, which can create problems. For instance, maybe a read-only device could try to open the (still old) database with a new non-empty journal file and sqlite would empty that journal file, then Dropbox could in turn empty the journal file before the writer client had finished the transaction. I am not (yet) going to test for and try to protect against more complicated (and rarer) edge cases where the database is in the middle of writing a transaction (which I suspect will only happen in case of crashes, not because of Dropbox, in which case the recovery of the database by the read-only client would actually be beneficial). -- Charles Parnot charles.par...@gmail.com http://app.net/cparnot twitter: @cparnot Your Lab Notebook, Reinvented. http://findingsapp.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any attachments are solely for the use of the addressee and may contain information that is privileged or confidential. Any disclosure, use or distribution of the information contained herein is prohibited. In the event this e-mail contains technical data within the definition of the International Traffic in Arms Regulations or Export Administration Regulations, it is subject to the export control laws of the U.S.Government. The recipient should check this e-mail and any attachments for the presence of viruses as L-3 does not accept any liability associated with the transmission of this e-mail. If you have received this communication in error, please notify the sender by reply e-mail and immediately delete this message and any attachments. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
seriously? you should fix and solve why the soft crashed in the first place, reality check please. But it is possible that Dropbox will copy a database and journal files that are not consistent with each other, which can create problems fix the sync process, that's easy. Best. On Mon, Jul 14, 2014 at 3:04 PM, Drago, William @ MWG - NARDAEAST william.dr...@l-3com.com wrote: This may be a bit simplistic, but it does give me a reasonable degree of confidence that hot journal files are being handled correctly in my application. I simply put a 1/0 on the line before my commit to purposely crash my app. Sure enough there's a journal file after the crash (I have a rather large transaction consisting of among other things, about 35 rows inserted, each containing a blob). When I restart my app it looks for the presence of a journal file and will open and read the db so that SQLite can deal with it. It also displays a message letting the user know that something went wrong during the last run. I do this with a test db of course, not the real one. -Bill -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- boun...@sqlite.org] On Behalf Of Charles Parnot Sent: Saturday, July 12, 2014 4:38 AM To: sqlite-users@sqlite.org Subject: [sqlite] capturing and testing a hot journal Hi all, For testing purposes of our application (a Mac app), I am generating what I thought would be a database with a hot journal using this approach (on an existing database): - open the database (and PRAGMA journal_mode = TRUNCATE;) - open a transaction: BEGIN IMMEDIATE TRANSACTION; - add some rows: INSERT etc... - **make a copy of the db and journal files** (while still hot?) - close the transaction Then I open the copied database+journal (naming the files appropriately), again in TRUNCATE journal mode. As expected, the content of the database does not include the inserted rows. However, the journal file is not emptied, even after closing the database. Based on the documentation (http://www.sqlite.org/lockingv3.html#hot_journals), I would have expected the journal file to be emptied because it is hot. There are 2 options here: - the journal file is actually not hot and I misunderstood the conditions that make it hot - there is a bug in SQLite Obviously, I strongly suspect I am misunderstanding things, and don't think it is an SQLite bug. Despite intensive Google-ing and more testing, I am not sure what makes the journal non-hot. Thanks for your help! Charles NB: You might be wondering why I am doing the above. I realize SQLite has already much more advanced tests for hot db+journals (running custom versions of filesystems to generate all kind of edge cases). The test case I am generating is just for a simple edge case of our Dropbox-based syncing (see: https://github.com/cparnot/PARStore and http://mjtsai.com/blog/2014/05/21/findings-1-0-and-parstore/). For a given database file, there is only one device that can write to it, all other devices being read-only (not in terms of filesystem, but sqlite- wise). But it is possible that Dropbox will copy a database and journal files that are not consistent with each other, which can create problems. For instance, maybe a read-only device could try to open the (still old) database with a new non-empty journal file and sqlite would empty that journal file, then Dropbox could in turn empty the journal file before the writer client had finished the transaction. I am not (yet) going to test for and try to protect against more complicated (and rarer) edge cases where the database is in the middle of writing a transaction (which I suspect will only happen in case of crashes, not because of Dropbox, in which case the recovery of the database by the read-only client would actually be beneficial). -- Charles Parnot charles.par...@gmail.com http://app.net/cparnot twitter: @cparnot Your Lab Notebook, Reinvented. http://findingsapp.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any attachments are solely for the use of the addressee and may contain information that is privileged or confidential. Any disclosure, use or distribution of the information contained herein is prohibited. In the event this e-mail contains technical data within the definition of the International Traffic in Arms Regulations or Export Administration Regulations, it is subject to the export control laws of the U.S.Government. The recipient should check this e-mail and any attachments for the presence of viruses as L-3 does not accept any liability associated with the transmission of this e-mail. If you have received this communication in error
Re: [sqlite] capturing and testing a hot journal
On 7/14/2014 6:38 PM, mm.w wrote: seriously? you should fix and solve why the soft crashed in the first place, reality check please. The software doesn't crash on its own; I'm forcing it to crash with a divide-by-zero for test purposes. This doesn't happen in actual use and there's no reason other than a power failure for a transaction to not commit successfully. But that doesn't mean I shouldn't handle a failed transaction if it ever does happen. -Bill But it is possible that Dropbox will copy a database and journal files that are not consistent with each other, which can create problems fix the sync process, that's easy. Best. On Mon, Jul 14, 2014 at 3:04 PM, Drago, William @ MWG - NARDAEAST william.dr...@l-3com.com wrote: This may be a bit simplistic, but it does give me a reasonable degree of confidence that hot journal files are being handled correctly in my application. I simply put a 1/0 on the line before my commit to purposely crash my app. Sure enough there's a journal file after the crash (I have a rather large transaction consisting of among other things, about 35 rows inserted, each containing a blob). When I restart my app it looks for the presence of a journal file and will open and read the db so that SQLite can deal with it. It also displays a message letting the user know that something went wrong during the last run. I do this with a test db of course, not the real one. -Bill -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- boun...@sqlite.org] On Behalf Of Charles Parnot Sent: Saturday, July 12, 2014 4:38 AM To: sqlite-users@sqlite.org Subject: [sqlite] capturing and testing a hot journal Hi all, For testing purposes of our application (a Mac app), I am generating what I thought would be a database with a hot journal using this approach (on an existing database): - open the database (and PRAGMA journal_mode = TRUNCATE;) - open a transaction: BEGIN IMMEDIATE TRANSACTION; - add some rows: INSERT etc... - **make a copy of the db and journal files** (while still hot?) - close the transaction Then I open the copied database+journal (naming the files appropriately), again in TRUNCATE journal mode. As expected, the content of the database does not include the inserted rows. However, the journal file is not emptied, even after closing the database. Based on the documentation (http://www.sqlite.org/lockingv3.html#hot_journals), I would have expected the journal file to be emptied because it is hot. There are 2 options here: - the journal file is actually not hot and I misunderstood the conditions that make it hot - there is a bug in SQLite Obviously, I strongly suspect I am misunderstanding things, and don't think it is an SQLite bug. Despite intensive Google-ing and more testing, I am not sure what makes the journal non-hot. Thanks for your help! Charles NB: You might be wondering why I am doing the above. I realize SQLite has already much more advanced tests for hot db+journals (running custom versions of filesystems to generate all kind of edge cases). The test case I am generating is just for a simple edge case of our Dropbox-based syncing (see: https://github.com/cparnot/PARStore and http://mjtsai.com/blog/2014/05/21/findings-1-0-and-parstore/). For a given database file, there is only one device that can write to it, all other devices being read-only (not in terms of filesystem, but sqlite- wise). But it is possible that Dropbox will copy a database and journal files that are not consistent with each other, which can create problems. For instance, maybe a read-only device could try to open the (still old) database with a new non-empty journal file and sqlite would empty that journal file, then Dropbox could in turn empty the journal file before the writer client had finished the transaction. I am not (yet) going to test for and try to protect against more complicated (and rarer) edge cases where the database is in the middle of writing a transaction (which I suspect will only happen in case of crashes, not because of Dropbox, in which case the recovery of the database by the read-only client would actually be beneficial). -- Charles Parnot charles.par...@gmail.com http://app.net/cparnot twitter: @cparnot Your Lab Notebook, Reinvented. http://findingsapp.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any attachments are solely for the use of the addressee and may contain information that is privileged or confidential. Any disclosure, use or distribution of the information contained herein is prohibited. In the event this e-mail contains technical data within the definition of the International Traffic in Arms Regulations or Export Administration Regulations, it is subject to the export control laws of the U.S.Government
[sqlite] capturing and testing a hot journal
Hi all, For testing purposes of our application (a Mac app), I am generating what I thought would be a database with a “hot” journal using this approach (on an existing database): - open the database (and PRAGMA journal_mode = TRUNCATE;) - open a transaction: BEGIN IMMEDIATE TRANSACTION; - add some rows: INSERT etc… - **make a copy of the db and journal files** (while still hot?) - close the transaction Then I open the copied database+journal (naming the files appropriately), again in TRUNCATE journal mode. As expected, the content of the database does not include the inserted rows. However, the journal file is not emptied, even after closing the database. Based on the documentation (http://www.sqlite.org/lockingv3.html#hot_journals), I would have expected the journal file to be emptied because it is “hot”. There are 2 options here: - the journal file is actually not “hot” and I misunderstood the conditions that make it hot - there is a bug in SQLite Obviously, I strongly suspect I am misunderstanding things, and don’t think it is an SQLite bug. Despite intensive Google-ing and more testing, I am not sure what makes the journal non-hot. Thanks for your help! Charles NB: You might be wondering why I am doing the above. I realize SQLite has already much more advanced tests for “hot” db+journals (running custom versions of filesystems to generate all kind of edge cases). The test case I am generating is just for a simple edge case of our Dropbox-based syncing (see: https://github.com/cparnot/PARStore and http://mjtsai.com/blog/2014/05/21/findings-1-0-and-parstore/). For a given database file, there is only one device that can write to it, all other devices being read-only (not in terms of filesystem, but sqlite-wise). But it is possible that Dropbox will copy a database and journal files that are not consistent with each other, which can create problems. For instance, maybe a read-only device could try to open the (still old) database with a new non-empty journal file and sqlite would empty that journal file, then Dropbox could in turn empty the journal file before the writer client had finished the transaction. I am not (yet) going to test for and try to protect against more complicated (and rarer) edge cases where the database is in the middle of writing a transaction (which I suspect will only happen in case of crashes, not because of Dropbox, in which case the recovery of the database by the read-only client would actually be beneficial). -- Charles Parnot charles.par...@gmail.com http://app.net/cparnot twitter: @cparnot Your Lab Notebook, Reinvented. http://findingsapp.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] capturing and testing a hot journal
On Sat, Jul 12, 2014 at 4:37 AM, Charles Parnot charles.par...@gmail.com wrote: Hi all, For testing purposes of our application (a Mac app), I am generating what I thought would be a database with a “hot” journal using this approach (on an existing database): - open the database (and PRAGMA journal_mode = TRUNCATE;) - open a transaction: BEGIN IMMEDIATE TRANSACTION; - add some rows: INSERT etc… - **make a copy of the db and journal files** (while still hot?) Normally you need to either (1) reduce the page cache size using PRAGMA cache_size=5 or else (2) do a VERY large transaction in order to get SQLite to spill content to disk in order to get a hot journal using the technique above. - close the transaction Then I open the copied database+journal (naming the files appropriately), again in TRUNCATE journal mode. As expected, the content of the database does not include the inserted rows. However, the journal file is not emptied, even after closing the database. Based on the documentation ( http://www.sqlite.org/lockingv3.html#hot_journals), I would have expected the journal file to be emptied because it is “hot”. There are 2 options here: - the journal file is actually not “hot” and I misunderstood the conditions that make it hot - there is a bug in SQLite Obviously, I strongly suspect I am misunderstanding things, and don’t think it is an SQLite bug. Despite intensive Google-ing and more testing, I am not sure what makes the journal non-hot. Thanks for your help! Charles NB: You might be wondering why I am doing the above. I realize SQLite has already much more advanced tests for “hot” db+journals (running custom versions of filesystems to generate all kind of edge cases). The test case I am generating is just for a simple edge case of our Dropbox-based syncing (see: https://github.com/cparnot/PARStore and http://mjtsai.com/blog/2014/05/21/findings-1-0-and-parstore/). For a given database file, there is only one device that can write to it, all other devices being read-only (not in terms of filesystem, but sqlite-wise). But it is possible that Dropbox will copy a database and journal files that are not consistent with each other, which can create problems. For instance, maybe a read-only device could try to open the (still old) database with a new non-empty journal file and sqlite would empty that journal file, then Dropbox could in turn empty the journal file before the writer client had finished the transaction. I am not (yet) going to test for and try to protect against more complicated (and rarer) edge cases where the database is in the middle of writing a transaction (which I suspect will only happen in case of crashes, not because of Dropbox, in which case the recovery of the database by the read-only client would actually be beneficial). -- Charles Parnot charles.par...@gmail.com http://app.net/cparnot twitter: @cparnot Your Lab Notebook, Reinvented. http://findingsapp.com ___ 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] capturing and testing a hot journal
On 12 Jul 2014, at 9:37am, Charles Parnot charles.par...@gmail.com wrote: - the journal file is actually not “hot” and I misunderstood the conditions that make it hot That one. The files on disk aren't 'hot' (as I think you mean it) while you're in a transaction. Your file system is not pushing journal changes at the file level. It doesn't need to do that while a transaction is open. since while the transaction is open, the database is locked so nothing else can use it anyway, and if your app crashes the whole transaction will be ignored. SQLite could be written to push transactions to the journal file on each change, but that would involve lots of writing to disk, so it would make SQLite slower, and for no gain. [snip] The test case I am generating is just for a simple edge case of our Dropbox-based syncing Yes, DropBox can be a problem for open SQLite databases. As a file level duplication system which does not understand locks, there's no good way to make DropBox work with open SQLite databases, or as a mediator for concurrent multi-user changes to a database. I had to explain to some users that a database change is not 'safe' until the database is closed. One thing that's worth testing is to make sure that recovery after crashes always yields a database with either pre- or post-transaction data rather than something corrupt which can't be opened. I don't know much about how DropBox works. Could it perhaps end up with a database file from one computer but journal file from another ? Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
