| Ticket Hash: | 5d863f876ee9561b95e279b3381450514b6da668 | |||
| Title: | DB corruption following rollback-WAL-VACUUM-rollback | |||
| Status: | Fixed | Type: | Code_Defect | |
| Severity: | Critical | Priority: | Immediate | |
| Subsystem: | Unknown | Resolution: | Fixed | |
| Last Modified: | 2011-01-27 14:33:00 | |||
| Version Found In: | 3.7.4 | |||
| Description: | ||||
An obscure method for corrupting databases has been discovered, involving
transitions between rollback journaling modes and WAL mode, with a VACUUM
thrown in the middle. The crux of the problem is that the change-counter
field at offset 24 in the database file was being reset to zero by the
sequence of commands:
PRAGMA journal_mode=WAL;
VACUUM;
PRAGMA journal_mode=DELETE;
The change-counter is used by database connections in rollback mode to detect when other database connections have modified the database, so that they can reset their caches. (Other mechanisms are used in WAL mode.) So if the change counter is initially zero (perhaps due to having previously run the command sequence shown above) and two database connections are hooked to the database in rollback mode and one connection modifies the database and then does the sequence of commands above, the other database connection will not notice the change and will hence perform subsequent operations using a stale cache. This can lead to database corruption. This malfunction was discovered during testing and has not been observed in the wild. | ||||