On March 13th, a corrective release 3.51.3 of the compact embedded DBMS took place. SQLite. The project code is written in C and is distributed as public domain.
Due to compatibility issues related to some new features, version 3.52.0 (released on March 6th) was withdrawn.
Change log for version 3.51.3:
- On March 3rd, one of the SQLite developers (Dan) identified and fixed a bug that could, in rare cases, lead to database corruption, referred to as "WAL-reset bug":
- This bug occurs only in databases operating in WAL mode when two or more connections to the same file are open in different threads or processes, and if these two connections attempt to write or create a checkpoint simultaneously.
- The bug is related to data access conflicts under tight time constraints. In normal operating conditions, it occurs very rarely. The developers were unable to reproduce this bug under natural conditions and had to add special testing logic to SQLite that intentionally creates conditions for the bug to ensure the issue was resolved.
- The bug occurs when:
- One connection is performing a checkpoint. This initial checkpoint must be completed. In other words, during the checkpoint, all content from the WAL file must be successfully copied back to the database, and the WAL file must be in a state that allows it to be reset.
- Immediately after the first checkpoint is completed, a second one begins.
- While the second checkpoint from step 2 is being executed, another connection to the database commits a transaction that resets the WAL file and writes new content to the beginning of the WAL file.
- Due to the data access conflict, the second checkpoint from step 2 does not account for the fact that the WAL file was reset as a result of the transaction commit in step 3. The second checkpoint sets an incorrect value for one of the fields in the WAL index header. This field indicates that part of the WAL file has already been committed in the checkpoint, although this is not the case.
- Committing additional transactions leads to an increase in the number of pages in the WAL file, exceeding the number of pages that existed at the time of the first checkpoint from step 1.
- Later, when a third checkpoint occurs, it skips all or part of the transaction recorded at stage 3. As a result, parts of the transaction from stage 3 do not make it into the database file, leading to database corruption.
- The bug is likely present in all versions of SQLite from 3.7.0 (July 21, 2010) to 3.51.2. Fixes have also been released for some earlier versions: 3.44.6 and 3.50.7.
- Other minor fixes.
Source: linux.org.ru
