On March 13th, a corrective release of 3.51.3 of the compact embedded DBMS was released. SQLiteThe project code is written in C and is distributed in the public domain.
Due to backward compatibility issues with some new features, version 3.52.0 (released on March 6) was withdrawn.
List of changes in version 3.51.3:
- On March 3rd, one of the SQLite developers (Dan) discovered and fixed a bug that could, in rare cases, lead to database corruption and is called WAL reset bug:
- This error occurs only in databases running in WAL mode if two or more connections are open to the same file in different threads or processes, and if the two connections attempt to write or create a checkpoint at the same time.
- The error is related to a data access conflict under strict time constraints. Under normal operating conditions, it occurs extremely rarely. The developers were unable to reproduce the error in the wild, and they were forced to add special testing logic to SQLite that deliberately creates conditions for the error to ensure the issue is resolved.
- The error occurs when:
- One connection performs a checkpoint. This first checkpoint must complete. In other words, the checkpoint must successfully copy the entire contents of the WAL file back to the database and bring the WAL file to a state that allows it to be flushed.
- Immediately after the first checkpoint is completed, the second one is launched.
- While the second checkpoint from step 2 is running, another database connection commits a transaction that flushes the WAL file and writes new contents to the beginning of the WAL file.
- Due to a data access conflict, the second checkpoint from step 2 doesn't take into account that the WAL file was flushed 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 was already committed at the checkpoint, although in fact this was not the case.
- Committing additional transactions causes the number of pages in the WAL file to grow beyond the number of pages that existed at the time of the first checkpoint in step 1.
- Later, when the third checkpoint occurs, it skips all or part of the transaction written in stage 3. Thus, parts of the transaction from stage 3 never make it into the database file, resulting in corruption of the database file.
- The bug appears to be present in all versions of SQLite, starting with 3.7.0 (2010-07-21) and ending with 3.51.2. Hotfixes have also been released for some earlier versions: 3.44.6 и 3.50.7.
- Other minor fixes.
Source: linux.org.ru
