Переработка 05cdf9d202b14ac09c801c7893e65271fa27f378. У предыдущего
варианта был недостаток, при необходимости выдачи предупреждения
и открытии БД с изменением геометрии, предупреждение не выдавалось,
что может затруднять анализ/разбор проблемных ситуаций.
Изменение геометрии (увеличение размера) больших БД может быть не
возможно после их открытия вследствие системных ограничений (отсутствия
свободного адресного пространства).
Поэтому API предусматривает возможность запросить изменение
геометрии/размера БД перед её открытием. В этом сценарии ранее могло
выдаваться лишнее/ненужное предупреждение о несоответствии файла БД
новому размеру. Теперь этот недостаток исправлен.
Спасибо Илье Михееву (Erigon) за сообщение об этом недочете.
Изменение геометрии (увеличение размера) больших БД может быть не
возможно после их открытия вследствие системных ограничений (отсутствия
свободного адресного пространства).
Поэтому API предусматривает возможность запросить изменение
геометрии/размера БД перед её открытием. В этом сценарии ранее могло
выдаваться лишнее/ненужное предупреждение о несоответствии файла БД
новому размеру. Теперь этот недостаток исправлен.
Спасибо Илье Михееву (Erigon) за сообщение об этом недочете.
Поддерживающий выпуск стабильной ветки с исправлением обнаруженных ошибок и устранением недочётов.
За перечнем доработок и изменений обращайтесь к [ChangeLog](https://libmdbx.dqdkfa.ru/md__change_log.html).
git diff' stat: 139 files changed, 391 insertions(+), 208 deletions(-)
Signed-off-by: Леонид Юрьев (Leonid Yuriev) <leo@yuriev.ru>
При сборке посредством GCC >= 11.4 больше не возникает предупреждений:
lto-wrapper: warning: using serial compilation of # LTRANS jobs
lto-wrapper: note: see the ‘-flto’ option documentation for more information
Однако, использование auto-режима не является оптимальным решением, так
как при параллельной сборке посредством make или ninja, каждая уже
запущенная ветвь компиляции породит потоки ещё для каждого ядра ЦПУ.
Таким образом реальная нагрузка может расти квадратично, т.е. чем больше
у вас ядер -- тем хуже и при 96 ядрах может работать 9216 потоков сборки.
Тем не менее, использование `job-server` в CMake пока не возможно, а при
сборке libmdbx не так много работы чтобы чтобы обрушить систему нагрузкой.
Ошибка внесена коммитом `a6f7d74a32a3cbcc310916a624a31302dbebfa07` от
2024-03-07 и присутствует в выпусках v0.13.1, v0.13.2, v0.13.3. Проблема
оставалась незамеченной из-за специфических условий и низкой вероятности
проявления.
Суть ошибки:
- функция cursor_touch() подготавливает стек страниц курсора к внесению
изменений, при этом все страницы в стеке (от корневой до листовой
в текущей позиции курсора) должны стать доступными для модификации.
- микрооптимизация добавленная коммитом пропускала обход стека, если
корневая страница уже доступна для модификации, но это
допустимо/корректно только при отсутствии в стеке вытесненных/spilled
страниц.
- если же складывалась ситуация когда в стека была вытесненная
некорневая страница, то она так и оставалась недоступной для записи и
при попытке её изменения возникал SIGSEGV.
Ошибка внесена коммитом `a6f7d74a32a3cbcc310916a624a31302dbebfa07` от
2024-03-07 и присутствует в выпусках v0.13.1, v0.13.2, v0.13.3. Проблема
оставалась незамеченной из-за специфических условий и низкой вероятности
проявления.
Суть ошибки:
- функция cursor_touch() подготавливает стек страниц курсора к внесению
изменений, при этом все страницы в стеке (от корневой до листовой
в текущей позиции курсора) должны стать доступными для модификации.
- микрооптимизация добавленная коммитом пропускала обход стека, если
корневая страница уже доступна для модификации, но это
допустимо/корректно только при отсутствии в стеке вытесненных/spilled
страниц.
- если же складывалась ситуация когда в стека была вытесненная
некорневая страница, то она так и оставалась недоступной для записи и
при попытке её изменения возникал SIGSEGV.
При переделке курсоров было пропущено отрицание в условии, при оценке
кол-ва страниц, которые могут потребоваться для выполнения операции.
В текущем понимании ошибка не приводила к каким-либо проблемам, ибо
оценка делает по верхней границе с существенным запасом, а в худшем
случае это могло приводить к прерыванию транзакции из-за достижения
ограничения на кол-во грязных страниц.
При переделке курсоров было пропущено отрицание в условии, при оценке
кол-ва страниц, которые могут потребоваться для выполнения операции.
В текущем понимании ошибка не приводила к каким-либо проблемам, ибо
оценка делает по верхней границе с существенным запасом, а в худшем
случае это могло приводить к прерыванию транзакции из-за достижения
ограничения на кол-во грязных страниц.
