Ticket Hash: | a4e06e75a9ab61a127088c4aaa85a6d7a1455f06 | |||
Title: | False-positive from "PRAGMA integrity_check" | |||
Status: | Fixed | Type: | Code_Defect | |
Severity: | Important | Priority: | Immediate | |
Subsystem: | Unknown | Resolution: | Fixed | |
Last Modified: | 2017-07-15 20:38:08 | |||
Version Found In: | 3.19.3 | |||
User Comments: | ||||
drh added on 2017-07-15 19:32:41:
The PRAGMA integrity_check at the end of the following sequence of code reports a "wrong # of entries" error, even though the database is intact and correct. CREATE TABLE Table1 (col TEXT NOT NULL PRIMARY KEY); ATTACH ':memory:' AS db2; CREATE TABLE db2.Table2(col1 INTEGER, col2 INTEGER, col3 INTEGER, col4 INTEGER); CREATE UNIQUE INDEX db2.idx_col1_unique ON Table2 (col1); CREATE UNIQUE INDEX db2.idx_col23_unique ON Table2 (col2, col3); CREATE INDEX db2.idx_col2 ON Table2 (col2); INSERT INTO Table2 VALUES(1,2,3,4); PRAGMA integrity_check; Bisecting shows that the problem first appeared with check-in [88439a866] on 2016-0319 and was first released with SQLite 3.12.0 on 2016-03-29 This problem was reported on the sqlite-users mailing list by Brendan E. Coughlan. drh added on 2017-07-15 20:38:08: When generating byte-code for an integrity_check on a connection with ATTACHed databases, the temporary register cache was not being reset after each database had been checked. If the schema for "main" was much simpler than the schema for the first attached database, this could cause cached temporary registers that overlapped with index row counters to be used, thus messing up the index row counts and leading to the "wrong # of rows" report. |