Временная подпорка для coherency_check(), которую в перспективе
следует заменить вместе с переделкой установки mod_txnid.
Суть проблемы:
- coherency_check() в качестве одного из критериев "когерентности"
проверяет условие meta.maindb.mod_txnid == maindb.root->txnid;
- при обновлении maindb.sequence высталяется DBI_DIRTY, что приведет
к обновлению meta.maindb.mod_txnid = current_txnid;
- однако, если в само дерево maindb обновление не вносились и оно
не пустое, то корневая страницы останеться с прежним txnid и из-за
этого ложно сработает coherency_check().
Временное (текущее) решение: Принудительно обновляем корневую
страницу в описанной выше ситуации. Это устраняет проблему, но и
не создает рисков регресса.
Итоговое решение, которое предстоит реализовать:
- изменить семантику установки/обновления mod_txnid, привязав его
строго к изменению b-tree, но не атрибутов;
- обновлять mod_txnid при фиксации вложенных транзакций;
- для dbi-хендлов пользовательских subDb (видимо) можно оставить
DBI_DIRTY в качестве признака необходимости обновления записи
subDb в MainDB, при этом взводить DBI_DIRTY вместе с обновлением
mod_txnid, в том числе при обновлении sequence.
- для MAIN_DBI при обновлении sequence не следует взводить DBI_DIRTY
и/или обновлять mod_txnid, а только взводить MDBX_TXN_DIRTY.
- альтернативно, можно перераспределить флажки-признаки dbi_state,
чтобы различать состояние dirty-tree и dirty-attributes.
Допускаем итерацию с не-вовлечением еще не-измененных страниц,
только когда страницы для объединения доступны справа и слева,
Т.е. допускаем итерацию для выбора лучшей альтернативы (справа или слева),
и избегаем этой итерации когда альтернативы нет.
Поддерживающий выпуск с исправлением обнаруженных ошибок и устранением недочетов,
в память об убитых в Крыму девочках 2 и 9 лет.
Лиза и Соня погибли 23 Июня 2024 на глазах у родителей, в результате
удара по общественному городскому пляжу ракетами ATACMS с кассетными
боеприпасами. Всего пострадало более 150 граждан России, в том числе 27
детей. Ракеты были выпущенными украинскими бандеровцами/фашистами, но
полетные задания формировались и загружались военными США, а управление
и наведение ATACAMS невозможно без использования орбитальной группировки
военных спутников США.
Основные исправления:
---------------------
- Исправление для ОС Windows нарезки `FILE_SEGMENT_ELEMENT`.
Похоже что был потерян коммит входе работы над оптимизацией пути записи
на диск в ОС Windows. В текущем понимании, вероятность проявления ошибки
достаточно низкая, так как выявлена она была синтетическими тестами в
ходе других доработок, а соответствующих сообщений/жалоб не поступало. К
повреждению БД ошибка не приводила, так как сбой происходил до записи
данных с возвратом `ERROR_INVALID_PARAMETER` из системного вызова, т.е.
либо ошибка не проявлялась, либо транзакция не фиксировалась.
- Устранение вероятности `SIGSEGV` при включении логирования
уровня `MDBX_LOG_TRACE` в отладочных сборках.
- Исправление генерации исключения `key_exists` в C++ API.
- Исправление обработки курсоров, открытых в родительских транзакциях и
закрытых до завершения вложенных транзакций. В описанной ситуации
закрытые курсоры "воскрешались", что приводило к утечке памяти
выделенной под такие курсоры.
- Костыль для MSVC ARM/ARM64 для предотвращения ICE (Internal Compiler Error).
- Устранение `MDBX_EINVAL` для случая вызова `mdbx_env_remove(".")`.
- Исправление инверсии bool-результата `env::remove()`в C++ API.
Более подробная информация в [ChangeLog](https://libmdbx.dqdkfa.ru/md__change_log.html).
git diff' stat: 29 commits, 14 files changed, 379 insertions(+), 151 deletions(-)
Signed-off-by: Леонид Юрьев (Leonid Yuriev) <leo@yuriev.ru>
Ошибка слишком грубая.
Похоже при переработке I/O под Windows при `git pull --rebase` потерялся коммит.
К повреждению БД проблема не приводила, так как сбой происходил во время записи данных с возвратом ERROR_INVALID_PARAMETER из системного вызова.
Ошибка слишком грубая.
Похоже при переработке I/O под Windows при `git pull --rebase` потерялся коммит.
К повреждению БД проблема не приводила, так как сбой происходил во время записи данных с возвратом ERROR_INVALID_PARAMETER из системного вызова.
