Технически такие записи не являются проблемными, а образовываются в
случае когда внутри update_gc() резервируется больше места, чем реально
остается номеров свободных страниц для возврата в GC.
Изначально такое избыточное резервирование считалось алгоритмическим
недостатком update_gc(). Поэтому утилита mdbx_chk была временно
доработана для выявления таких случаев в ходе стохастических тестов.
Постепенно все реальные недочеты update_gc() (если не считать
запутанности и неочевидности кода) были устранены, формирование пустых
записей в GC не наблюдалось и излишне строгий контроль в mdbx_chk не
создавал проблем.
В ходе же последних точечных доработок была предпринята попытка еще
немного уменьшить затраты ЦПУ внутри update_gc(), в частности уменьшить
кол-во циклов/повторов посредством улучшения сходимости, а также
уменьшить WAF. При этом образование пустых записей в GC стало возможным
в достаточно редких ситуациях, когда (например) для возврата в GC
остается только одна страница и добавление записи единичной длины
приводит к перебалансировке или разделению листовой страницы по
легковесному пути, без вовлечения других страниц дерева и без
переработки дополнительных записей GC, но с поглощением остававшейся на
возврат страницы.
Проще говоря, в актуальная версии MDBX пустые записи в GC могут
образовываться, когда это энергетически выгодно. Тогда как в предыдущих
выпусках в таких ситуациях выполнялось более дорогое обновление GC с
переработкой и возвратом дополнительных записей.
Существенных последствий ошибки не было (иначе бы давно было замечено).
Но в определенных сценариях, сходимость требовала еще одного цикла
повтора внутри update_gc().
Существенных последствий ошибки не было (иначе бы давно было замечено).
Но в определенных сценариях, сходимость требовала еще одного цикла
повтора внутри update_gc().
Поддерживающий выпуск с исправлением обнаруженных ошибок и устранением недочетов
в память Героя России гвардии майора Дмитрия Семёнова с позывным "СЭМ".
Значимые исправления и доработки:
---------------------------------
- Устранение унаследованной от LMDB ошибки приводящей к повреждению БД при использовании `MDBX_DUPFIXED`.
- Исправление ложной ошибки `MDBX_CORRUPTED (-30796)` в сценарии работы
в режиме `MDBX_DUPFIXED` и нечетной длинной мульти-значений.
- Исправление недочета корректировки сопутствующих курсоров при разделении страницы
по сценарию добавления пустой страницы слева.
- Доработка `rebalance()` ради уменьшения WAF.
- Исправление assert-проверки внутри `check_txn()` для случая завершенных транзакций в режиме `MDBX_NO_TLS`.
Последствий ошибки, кроме срабатывания assert-проверки в отладочных сборках, нет.
- Устранение ошибки при открытии БД на файловой системе только-для-чтения.
- Удалены излишне строгие проверки в утилите `mdbx_chk`, которые
приводили к ложно-позитивным ошибкам при проверке БД после серии
последних доработок.
Более подробная информация в [ChangeLog](https://libmdbx.dqdkfa.ru/md__change_log.html).
git diff' stat: 19 commits, 57 files changed, 751 insertions(+), 331 deletions(-)
Signed-off-by: Леонид Юрьев (Leonid Yuriev) <leo@yuriev.ru>
Коммитом 36a7e7ac24fa1817cac83d5e7ae6e351e7cb580b был скорректирован
подсчет места занимаемого заголовками и данными. В частности, байты
занимаемые заголовков вложенной под-страницы теперь относится к
заголовкам, а не пользовательским данным.
Однако, в случае когда на под-странице, созданной для хранения куста
мульти-значений (MDBX_DUPSORT), после серии удалений остаётся одно
значение, которое в MDBX может нулевой длины, получается под-страница с
нулевым количеством пользовательских данных. Этот коммит исправляет
Технически такие записи не являются проблемными, а образовываются в
случае когда внутри update_gc() резервируется больше места, чем реально
остается номеров свободных страниц для возврата в GC.
Изначально такое избыточное резервирование считалось алгоритмическим
недостатком update_gc(). Поэтому утилита mdbx_chk была временно
доработана для выявления таких случаев в ходе стохастических тестов.
Постепенно все реальные недочеты update_gc() (если не считать
запутанности и неочевидности кода) были устранены, формирование пустых
записей в GC не наблюдалось и излишне строгий контроль в mdbx_chk не
создавал проблем.
В ходе же последних точечных доработок была предпринята попытка еще
немного уменьшить затраты ЦПУ внутри update_gc(), в частности уменьшить
кол-во циклов/повторов посредством улучшения сходимости, а также
уменьшить WAF. При этом образование пустых записей в GC стало возможным
в достаточно редких ситуациях, когда (например) для возврата в GC
остается только одна страница и добавление записи единичной длины
приводит к перебалансировке или разделению листовой страницы по
легковесному пути, без вовлечения других страниц дерева и без
переработки дополнительных записей GC, но с поглощением остававшейся на
возврат страницы.
Проще говоря, в актуальная версии MDBX пустые записи в GC могут
образовываться, когда это энергетически выгодно. Тогда как в предыдущих
выпусках в таких ситуациях выполнялось более дорогое обновление GC с
переработкой и возвратом дополнительных записей.
После предыдущей серии доработок весной 2021 года, функция `rebalance()`
обеспечивала слияние мало заполненной страницы с менее заполненной
соседней, одновременно пытаясь не вовлекать соседних страниц, если те
еще не были скопированы/клонированы/изменены в текущей транзакции.
В целом, реализованная тактика представляется успешной. Однако, при
обновлении GC она иногда приводила к исчерпанию подготовленного резерва
извлеченных из GC страниц. Это не является проблемой, если не считать
вероятность срабатывания `assert(txn->mt_flags & MDBX_TXN_DRAINED_GC)`
в отладочных сборках.
Тем не менее, из этой ситуации можно сделать вывод, что поведение
`rebalance()`, как минимум, может быть обогащено опцией уменьшения WAF
ценой меньшей сбалансированности дерева. Технически при этом слияние
выполняется преимущественно с грязной страницей, если на ней достаточно
места и соседняя страница с другой стороны еще чистая.
ВАЖНО: Соответствующая опция в `enum MDBX_option_t` будет добавлена чуть
позже в следующую версию, а в текущих ветках `master` и `stable` это
именение поведение будет заглушено.
Тезисно:
- Использование DUPFIXED (включая INTEGERDUP) могло приводить к
повреждению БД и/или потере данных. Этот коммит устраняет эту угрозу.
- Вероятность проявления существенно увеличивается с увеличением
размера/длины мульти-значений/дубликатов (не ключей).
- В MDBX проблема унаследована от LMDB, где существует более 11 лет,
начиная с коммита ccc4d23e74
и до настоящего времени.
Для вложенных страниц типа LEAF2 (которые содержат только значения
одинаковой длины, без таблицы смещений к ним), упомянутым выше коммитом,
было добавлено резервирование места (что в целом спорно, но в некоторых
сценариях позволяет уменьшить накладные расходы). Ошибка была в том, что
в коде не исключалась возможность превышения размера страницы БД, что
далее приводило к арифметическому переполнению, повреждению БД и/или
просписи памяти.
Устранение упущения приводящего к нелогичной ситуации `me_dxb_mmap.curren > me_dxb_mmap.limit` при "дребезге" размера БД.
В текущем понимании, последствий кроме срабатывания assert-проверки нет, а вероятность проявления близка к нулю.
Повреждение БД и/или потери данных не происходило, проблема лишь в
возврате ложной ошибки.
Благодарю пользователя/разработчика @Dvirsw (https://t.me/Dvirsw) за
сообщения о проблеме и предоставление минимального/оптимального сценария
воспроизведения.
--
Проблема была из-за излишнего условия при контроле внутренего поля
mp_upper в ходе проверки структуры страниц БД.
Поле mp_upper указывает на нижнуюю границу заполнения страницы от конца
к началу. Вследствие того, что значения ключей выравниваетня на четную
границу, это поле четно во всех случаях за исключением LEAF2-страницы
(листовая страница вложенного дерева для множественных значений
финсированной/одинаковой длины одного ключа), на которой размещено
нечетное количество значений нечетной длины.
Ошибка не проявлялась в большинстве случаев (в том числе в
стохастических тестах), так как штатно лишняя проверка производилась
только при чтении страницы и перебалансировке ключей, но не при каждом
добавлении значения. Тем не менее, сценарии тестов требуют
доработки/расширения для явного добавления нечетных dupfixed-сценариев.
В текущем понимании коммитом этим устраняется застарелая проблема редких
сбоев стохастического теста из-за вероятности ошибочной генерации
повторяющихся пар key-value.
После предыдущей серии доработок весной 2021 года, функция `rebalance()`
обеспечивала слияние мало заполненной страницы с менее заполненной
соседней, одновременно пытаясь не вовлекать соседних страниц, если те
еще не были скопированы/клонированы/изменены в текущей транзакции.
В целом, реализованная тактика представляется успешной. Однако, при
обновлении GC она иногда приводила к исчерпанию подготовленного резерва
извлеченных из GC страниц. Это не является проблемой, если не считать
вероятность срабатывания `assert(txn->mt_flags & MDBX_TXN_DRAINED_GC)`
в отладочных сборках.
Тем не менее, из этой ситуации можно сделать вывод, что поведение
`rebalance()`, как минимум, может быть обогащено опцией уменьшения WAF
ценой меньшей сбалансированности дерева. Технически при этом слияние
выполняется преимущественно с грязной страницей, если на ней достаточно
места и соседняя страница с другой стороны еще чистая.
Соответствующая опция в `enum MDBX_option_t` будет добавлена чуть позже.
Тезисно:
- Использование DUPFIXED (включая INTEGERDUP) могло приводить к
повреждению БД и/или потере данных. Этот коммит устраняет эту угрозу.
- Вероятность проявления существенно увеличивается с увеличением
размера/длины мульти-значений/дубликатов (не ключей).
- В MDBX проблема унаследована от LMDB, где существует более 11 лет,
начиная с коммита ccc4d23e74
и до настоящего времени.
Для вложенных страниц типа LEAF2 (которые содержат только значения
одинаковой длины, без таблицы смещений к ним), упомянутым выше коммитом,
было добавлено резервирование места (что в целом спорно, но в некоторых
сценариях позволяет уменьшить накладные расходы). Ошибка была в том, что
в коде не исключалась возможность превышения размера страницы БД, что
далее приводило к арифметическому переполнению, повреждению БД и/или
просписи памяти.
