Checkpoint SQLite: успех обслуживания нужно читать вместе с режимом и счётчиками
Фотография конкретного исполнения не приложена.
PASSIVE переносит столько WAL-страниц, сколько возможно без ожидания завершения читателей или писателя; такой checkpoint может остаться неполным. FULL, RESTART и TRUNCATE имеют дополнительные условия ожидания. Выбор режима определяет влияние обслуживания на работающую запись, поэтому его нельзя скрывать за общей кнопкой «очистить журнал».
RESTART дополнительно ждёт возможности заново использовать WAL с начала, а TRUNCATE при успешном завершении сокращает файл до нулевого размера. Обычный завершённый checkpoint не обязан физически уменьшать файл: его пространство может использоваться повторно. Сравнение только размеров до и после не объясняет результат операции.
SQLITE_BUSY способен возвращаться после частичного прогресса при соответствующих режимах и ограничении ожидания. Для диагностики сохраняют код, выбранный режим и выходные счётчики кадров. Область базы также задают явно: при обслуживании всех attached-баз смысл выходных параметров отличается от вызова для одной конкретной базы.
В приёмке проверяют свободную базу и базу с согласованным длительным читателем. Сверяют прогресс и время блокирования. Удаление файла средствами операционной системы не заменяет checkpoint и не является допустимым доказательством, что данные уже перенесены в основной файл.
Основание — SQLite official unversioned documentation snapshot; Download index observed 3.54.1, individual pages not version-tagged, разделы Checkpoint modes and outputs. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Установленная библиотека, сборка, файловая система и база узла не проверялись. Это проектный сценарий; SQL и сервисные операции на реальных данных не выполнялись.
