На штатную работу это никак не влияет, но немного облегчит разбор
ситуаций когда глобальный конструктор не вызывается, либо делается
попытка вызвать его дважды (из-за ошибок rtc/libc, etc).
Ранее проверка внутри cursor_seek() не позволяла искать ключи длиннее чем можно поместить в таблицу,
что при поиске/позиционировании не является ошибкой для ключей переменного размера.
При включении LTO анализатор путей выполнения внутри GCC начинает укачивать из-за выражений вида `return LOG_IFERR(MDBX_EINVAL);`
Проблема в том, что несмотря на __builtin_assume() и __builtin_unreachable(), комплятор не хочет
видеть что функция log_if_error() всегда возвращает получаемое значение. А если допустить что значение
будет изменено, то вместо ошибки может быть MDBX_SUCCESS, и тогда в вызывающем как-бы может произойти
обращение к неинициализированным данным, что и беспокоит компилятор.
Например, при сборке mdbx_load:
‘txn_info.txn_space_dirty’ may be used uninitialized [-Wmaybe-uninitialized]
Проэтому проще пойти анализатору навстречу и упростить исходный код.
Теперь код ошибки явно пробрасывается через тело inline-функции, но это
требует 1-2 дополнительных процессорных инструкции на каждое применение
макроса LOG_IFERROR.
Также здесь откатывается коммит 81a8127084d9a6a7777bb375e029062330e51979.
При добавлении нового ключа в append-режиме, в случае когда в текущей
(последней) позиции с ключом связаны несколько значений и
(соответственно) вложенный dupsort-курсор инициализирован, вставка
происходила без сброса вложенного курсора.
В результате вложенный курсор логически оставался стоять на
multivalue-данных связанных с предыдущей позицией основного курсора,
т.е. переходил в неконсистентное состояние.
Ошибка проявлялась возвратом неверных значений из mdbx_cursor_count()
или срабатывание assert-проверки в отладочных сборках.
Из LXC-контейнера не доступен файл хостовой системы "/proc/sys/kernel/random/boot_id".
Вместо него, при каждом старте контейнера, создается и заполняется
случайными данными собственный boot_id смонтированный через bind из tmpfs.
https://github.com/lxc/lxc/issues/3027
Поэтому полноценный контроль по boot_id не возможен, так как при
рестарте LXC-контейнера (но не хоста) boot_id будет меняться, хотя
данные в unified page cache сохраняются.
Таким образом, при рестарте LXC-контейнера, libmdbx будет производить
откат БД до крайней точки устойчивой фиксации, что может приводить к
утрате данных пользователя в случаях когда они могли быть сохранены.
Однако, улучшить ситуацию пока не представляется возможным, как минимум
до доступности boot_id хостовой системы изнутри LXC-контейнера.
Этот коммит частично улучшает ситуацию тем, что позволяет использовать
фейковый/замещенный boot_id размещенный в файловой системе с типом tmpfs
при работе внутри LXC-контейнера.
Возможность полезная, но пожалуй еще нуждается в доработке и/или
до-осмыслении. Основное неудобство в нестыковке с основным логированием.
С одной стороны, сообщение об ошибках следует выводить с
уровнем/severity MDBX_LOG_ERROR. Однако, это замусоривает и ломает
тесты.
Поэтому сейчас при возвращении ошибок из API сообщения логируются
MDBX_LOG_ERROR, но производится это только при включении уровня
логирования MDBX_LOG_DEBUG или более детальном.
Было `MAJOR.MINOR.RELEASE.REVISION`
Теперь `MAJOR.MINOR.PATCH[.TWEAK][-PRERELEASE][+BUILDMETADATA]`
https://semver.org/
- вместо квартета `MAJOR.MINOR.RELEASE.REVISION`
триплет c опцинальным четвертым членом `MAJOR.MINOR.PATCH[.TWEAK]`
- `TWEAK` не входит в тег git, а формируется автоматически и
соответствует кол-ву коммитов после тега git и опускается если 0.
- Поле `PRERELEASE` опционально и переносится в версию из тега git.
- Поле `BUILDMETADATA` опционально, не входит в тег git, а
добавляется во время сборки если задана опцией `MDBX_BUILD_METADATA`.
Изменение поведения по-умолчанию, но без утраты контроля.
Без изменения:
Определение опции MDBX_WITHOUT_MSVC_CRT в значение 0 или 1 позволяет явно выбирать между использование ntdll и CRT.
При этом включение C++ API (MDBX_BUILD_CXX=1) требует использования CRT.
Ранее:
По-умолчанию, когда не определены опции MDBX_WITHOUT_MSVC_CRT и MDBX_BUILD_CXX, делался выбор в пользу использования ntdll, вместо CRT.
Теперь:
Функции ntdll будет использоваться вместо CRT только если явно выключена поддержка C++ API (задано MDBX_BUILD_CXX=0).
Исторически в API была слабость/неоднозначность в жизненном цикле читающих транзакций:
- В простейших сценариях читающие транзакции запускались посредством
mdbx_txn_begin() и завершались посредством mdbx_txn_abort(), либо mdbx_txn_commit();
- Для экономии накладных расходов были предусмотрены функции
mdbx_txn_reset() и mdbx_txn_renew(), которые сбрасывали/прерывали
читающую транзакцию без её освобождения/разрушения и затем перезапускали её.
При этом транзакции сброшенные посредством mdbx_txn_reset() должны были
быть либо перезапущены, либо освобождены посредством mdbx_txn_abort();
- Заминка возникала при вызове mdbx_txn_commit() для читающих
транзакций сброшенных/прерванных посредством mdbx_txn_reset().
В таких ситуациях возвращалась ошибка MDBX_BAD_TXN, а транзакция
не освобождалась.
Такое поведение вносило лишнюю асимметрию в API и способствовало
появлению ошибок утечки ресурсов, но поддерживалось для совместимости.
Этот коммит изменяет историческое поведение с нарушением совместимости,
но делает API более регулярным и уменьшает вероятность ошибок утечки
ресурсов.
Теперь mdbx_txn_commit() освобождает/разрушает читающие транзакции
сброшенные/прерванные посредством mdbx_txn_reset() возвращая при этом
MDBX_RESULT_TRUE вместо MDBX_SUCCESS, по аналогии обработки фиксации
аварийных пишущих транзакций.
