SQLite

View Ticket
Login
2017-07-15
20:44
Merge the fix for ticket [a4e06e75a9ab61a12] from trunk. (check-in: b64d64c8 user: drh tags: branch-3.20)
20:38 Fixed ticket [a4e06e75]: False-positive from "PRAGMA integrity_check" plus 6 other changes (artifact: d02faf27 user: drh)
20:33
Fix a register allocation problem in PRAGMA integrity_check that caused the same register to be used for two different purposes on the first ATTACHed database if the schema for the ATTACHed database was noticable more complex than the schema for the first database. Fix for ticket [a4e06e75a9ab61a1]. (check-in: 253945d4 user: drh tags: trunk)
19:32 New ticket [a4e06e75] False-positive from "PRAGMA integrity_check". (artifact: 1cd21727 user: drh)

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.