В текущем понимании коммитом этим устраняется застарелая проблема редких
сбоев стохастического теста из-за вероятности ошибочной генерации
повторяющихся пар 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 (которые содержат только значения
одинаковой длины, без таблицы смещений к ним), упомянутым выше коммитом,
было добавлено резервирование места (что в целом спорно, но в некоторых
сценариях позволяет уменьшить накладные расходы). Ошибка была в том, что
в коде не исключалась возможность превышения размера страницы БД, что
далее приводило к арифметическому переполнению, повреждению БД и/или
просписи памяти.
Устранение упущения приводящего к нелогичной ситуации `me_dxb_mmap.curren > me_dxb_mmap.limit` при "дребезге" размера БД.
В текущем понимании, последствий кроме срабатывания assert-проверки нет, а вероятность проявления близка к нулю.
Повреждение БД и/или потери данных не происходило, проблема лишь в
возврате ложной ошибки.
Благодарю пользователя/разработчика @Dvirsw (https://t.me/Dvirsw) за
сообщения о проблеме и предоставление минимального/оптимального сценария
воспроизведения.
--
Проблема была из-за излишнего условия при контроле внутренего поля
mp_upper в ходе проверки структуры страниц БД.
Поле mp_upper указывает на нижнуюю границу заполнения страницы от конца
к началу. Вследствие того, что значения ключей выравниваетня на четную
границу, это поле четно во всех случаях за исключением LEAF2-страницы
(листовая страница вложенного дерева для множественных значений
финсированной/одинаковой длины одного ключа), на которой размещено
нечетное количество значений нечетной длины.
Ошибка не проявлялась в большинстве случаев (в том числе в
стохастических тестах), так как штатно лишняя проверка производилась
только при чтении страницы и перебалансировке ключей, но не при каждом
добавлении значения. Тем не менее, сценарии тестов требуют
доработки/расширения для явного добавления нечетных dupfixed-сценариев.
Стабилизирующий выпуск с исправлением обнаруженных ошибок и устранением недочетов.
Исправления и доработки:
------------------------
- Ликвидация зависимости от ранее удаленной опции `MDBX_ENABLE_PREFAULT`, из-за
чего опция `MDBX_ENABLE_MINCORE` не включалась автоматически, что приводило
к не-активации соответствующего улучшения и не-достижению декларируемого уровня
производительности в сценариях использования в режиме `MDBX_WRITEMAP`.
- Исправление авто-установки `MDBX_ENV_CHECKPID` при отключении использования
функционала `madvise()` посредством опции сборки `MDBX_ENABLE_MADVISE=0`.
Из-за чего при поддержке системой `madvise(MADV_DONTFORK)` не включался контроль pid.
- Добавлена проверка переданного ключа на `NULL` при обработке `MDBX_GET_MULTIPLE`.
- Добавлена проверка номеров корневых страниц в `coherency_check()`.
- Обеспечен `const` для начала и конца диапазона в аргументах `mdbx_estimate_range()`.
- Из разрабатываемой версии перенесены не-нарушающие совместимости доработки C++ API:
- добавлен тип `mdbx::cursor::estimation_result`, а поведение методов
`cursor::estimate()` унифицировано с `cursor::move()`;
- для предотвращения незаметного неверного использования API, для инициализации
возвращаемых по ссылке срезов, вместо пустых срезов задействован `slice::invalid()`;
- добавлены дополнительные C++ операторы преобразования к типам C API;
- для совместимости со старыми стандартами C++ и старыми версиями STL перенесены
в public классы `buffer::move_assign_alloc` и `buffer::copy_assign_alloc`;
- добавлен тип `mdbx::default_buffer`;
- для срезов и буферов добавлены методы `hex_decode()`, `base64_decode()`, `base58_decode()`;
- добавлен тип `mdbx::comparator` и функций `mdbx::default_comparator()`;
- добавлены статические методы `buffer::hex()`, `base64()`, `base58()`;
- для транзакций и курсоров добавлены методы `get_/set_context`;
- добавлен метод `cursor::clone()`;
- Поддержка base58 приведена в соответствии с черновиком RFC.
- Переработка/исправление `to_hex()` и `from_hex()`.
- Уменьшение `MDBX_opt_rp_augment_limit` по умолчанию до 1/3 от текущего количества страниц в БД.
Более подробная информация в [ChangeLog](https://libmdbx.dqdkfa.ru/md__change_log.html).
git diff' stat: 32 commits, 8 files changed, 667 insertions(+), 401 deletions(-)
Signed-off-by: Леонид Юрьев (Leonid Yuriev) <leo@yuriev.ru>
После f0d523c507042cc70eeeb690778c9b2be6a8b33f, при использовании
добавленного API блокировок, возможно ложно-положительное определение
состояние "внутри транзакции".
Когда rp_augment_limit не задан пользователем посредством
`MDBX_opt_rp_augment_limit`, то как и ранее он подстраивается в
зависимости от текущего размера БД (актуального кол-ва страниц).
Теперь-же авто-устанавливаемое значение rp_augment_limit вычисляется
обратно-пропорционально `MDBX_opt_gc_time_limit`:
- Если gc_time_limit == 0, то rp_augment_limit устанавливается в 1/3 от
общего кол-ва страниц БД, но не меньше рационального минимума.
Это соответствует прежнему поведению и обеспечивает достаточно глубокую
переработку GC во всех не-экстремальных сценариях.
- При gc_time_limit >= 16_секунд
rp_augment_limit устанавливается в минимальное значение.
- Когда 0 < gc_time_limit < 16_секунд
rp_augment_limit устанавливается между минимумом и 1/3 от размера БД
пропорционально остатку gc_time_limit до 16 секунд.
Соответственно, при больших значениях gc_time_limit, выбирается меньшее
значение rp_augment_limit, и контроль глубины переработки GC
ограничивается в основном по-времени.
