Исправление aist1, (текущая версия) :
Проверил код wal.c SQLite. Дело, короче, такое. Накатывание WAL на файл БД, действительно, не атомарное. НО, если произойдет крэш во время чекпоинта, то чекпоинт можно будет просто повторить после крэша. Что и произойдет, если БД будет открыта с наличествующим WAL-файлом.
Если при крэше во время чекпоинта WAL будет потерян, то будет повреждение файла БД.
Я такую схему считаю устойчивой к крэшам. В ситуациях, когда предварительно (перед чекпоинтом) fsync-нутый WAL может потеряться при крэше, может еще много чего произойти и с самим файлом БД, от чего уже не защитишься на уровне самой БД.
Исходная версия aist1, :
Проверил код wal.c SQLite. Дело, короче, такое. Накатывание WAL на файл БД, действительно, не атомарное. НО, если произойдет крэш во время чекпоинта, то чекпоинт можно будет просто повторить после крэша. Что и произойдет, если БД будет открыта с наличествующим WAL-файлом.
Если при крэше WAL будет потерян, то будет повреждение файла БД.
Я такую схему считаю устойчивой к крэшам. В ситуациях, когда предварительно (перед чекпоинтом) fsync-нутый WAL может потеряться при крэше, может еще много чего произойти и с самим файлом БД, от чего уже не защитишься на уровне самой БД.