Using 3.7.14, when creating an index on a 27G database (on the table that contains almost all of the data), I consistently (on Windows XP and Debian GNU/Linux, on three different machines) get a disk I/O error. This does not happen using 3.7.13 (only tested on Debian GNU/Linux), nor does it happen when creating the same index on a smaller (~2G) version of the database.
I ran the process under strace; the final relevant lines (as far as I can judge, knowing nothing of this) are: lseek(5, 23934032896, SEEK_SET) = 23934032896 write(5, "\231\216\344\271\213\351\235\240\345\261\261\n+\367K\340*\5\2I \1\4\v\3 01\351\276\215\345\202\276\346\271"..., 1024) = 1024 lseek(5, 23934033920, SEEK_SET) = 23934033920 write(5, "\207\345\210\245\347\267\207\347\264\240\346\211\200\350\254 \202\346\2 11\223\351\274\223\345\274\204\n+\367u\334*\5"..., 632) = 632 lseek(5, 0, SEEK_SET) = 0 read(5, 0x7f5462cb06b8, 18446744071873782392) = -1 EFAULT (Bad address) close(5) = 0 The command that causes the error is "CREATE INDEX IF NOT EXISTS TextNGramIndex ON TextNGram (text, ngram, size)". The database schema is (without the failing index): CREATE TABLE Text ( id INTEGER PRIMARY KEY ASC, filename TEXT UNIQUE NOT NULL, checksum TEXT NOT NULL, label TEXT NOT NULL ); CREATE TABLE TextHasNGram ( text INTEGER NOT NULL REFERENCES Text (id), size INTEGER NOT NULL ); CREATE TABLE TextNGram ( text INTEGER NOT NULL REFERENCES Text (id), ngram TEXT NOT NULL, size INTEGER NOT NULL, count INTEGER NOT NULL ); CREATE UNIQUE INDEX TextHasNGramIndex ON TextHasNGram (text, size); CREATE INDEX TextIndexLabel ON Text (label); Is there more information I should provide as part of a proper bug report, or is this a known issue, or have I missed a trick somewhere? Jamie _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users