*** 8,13 **** --- 8,52 ---- and ticket #2224. ---- + **Fixed in Version 3.5.4 (2007-12-14):** + + Any DELETE or UPDATE operation that uses side-effects + to delete additional rows + of the same table that is the subject of the DELETE or UPDATE + might cause database corruption. The issue was first identified + by ticket #2832. But the issue is very old and effects all + versions of SQLite at least back through version 3.3.13 (the + earliest version that we have checked.) + + A "delete side-effect" in the previous paragraph means a + deletion that occurs as a result of an OR REPLACE clause + or due to a trigger. For example: + + CREATE TABLE ex1(a INTEGER PRIMARY KEY, b); + INSERT INTO ex1 VALUES(1,2); + INSERT INTO ex1 VALUES(2,3); + CREATE TRIGGER ex1_tr1 AFTER UPDATE ON ex1 BEGIN + DELETE FROM ex1 WHERE a=old.b; + END; + + UPDATE ex1 SET b=b+1; + + In the example above, the first cycle of the UPDATE causes + the trigger to fire and delete the second row of the ex1 + table. When the second cycle of the UPDATE loop runs, it + attempts to process the second row of the ex1 table. SQLite + recognized that the second row had been deleted so it aborts + the second cycle, but it was + failing to clean up after itself properly which could lead + to database corruption on subsequent cycles of the loop. + + The simple example above would not cause database corruption. + In fact, the usual result of this bug is a segmentation fault. + Getting the system to corrupt the database rather than segfault + is very difficult. Nevertheless, it is possible, as ticket + #2832 demonstrated. + + ---- **Fixed in Version 3.5.1 (2007-10-04):** If an SQLITE_FULL error occurs within an explicit transaction
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|