I think the ATTACH slowness was a misunderstanding caused by the optimization as it does not happen anymore now I compiled with -O0. The long time was actually deleting the table from the input db, this explains also why sqlite was making the journal file for the operation.
I am aware it sounds implausible, but I really have not idea why the standard error message was not appearing before. Yes, I am using Linux % uname -a Linux slyrogue 4.1.4-1-ARCH #1 SMP PREEMPT Mon Aug 3 21:30:37 UTC 2015 x86_64 GNU/Linux About hardware failures I do read some: mce: [Hardware Error]: Machine check events logged lines in dmesg. I try to investigate more. On Tue, Aug 18, 2015 at 12:28 PM, Simon Slavin <slavins at bigfraud.org> wrote: > > On 18 Aug 2015, at 4:14am, Paolo Bolzoni <paolo.bolzoni.brown at gmail.com> > wrote: > >> In the input and output database I had a table of the same name and using: >> >> DROP TABLE IF EXISTS WaysNodes; >> >> sqlite3 was actually deleting the table of the input db, this was >> unexpected as I thought that >> without any prefix it deleted from the main database. > > So did I. I'm glad you have a working solution but there is still something > wrong. Not only is your text above correct but it shouldn't take 13 hours to > do an integrity check on a 13 Gig database with simple indexes. > > I'm still suspecting some kind of hardware problem. I'll be interested to > know what happens if you ATTACH your copy of the input database, on the other > disk, rather than the original. Does it still take a very long time ? > > Hmm. What OS are you using again ? Oh, you used iostat. Linux. So not the > Windows pre-read caching bug. Okay. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
