Запуск читающих и пишущих транзакций взаимно не блокируется. Однако,
внутри одного процесса, DBI-хендлы и атрибуты таблиц используются
совместно всеми транзакциями (в рамках экземпляра среды работы с БД).
Поэтому после изменения атрибутов таблиц, в том числе при первоначальном
чтении актуальных атрибутов MainDB, может возникать состояние гонок при
одновременном старте нескольких транзакций.
Этим коммитом исправляются недочеты в обработке ситуации таких гонок,
из-за чего могла возвращается неожиданная (с точки зрения пользователя)
ошибка `MDBX_BAD_DBI`.
Формально ошибка присутствовала начиная с коммита `e6af7d7c53428ca2892bcbf7eec1c2acee06fd44` от 2023-11-05.
Однако, до этого (исторически, как было унаследовано от LMDB)
отсутствовал какой-либо контроль смены атрибутов MainDB во время старта
и/или работы транзакций. Поэтому вместо возврата каких-либо ошибок
подобные состояние гонок и/или связанные с изменением атрибутов MainDB
оставались необработанными/незамеченными, либо проявлялись как редкие
неуловимые сбои пользовательских приложений.
Спасибо [Артёму Воротникову](https://github.com/vorot93) за сообщение о проблеме!
В случае ошибки запуска транзакции (например из-за невозможности расширения отображения при увеличении БД в другом процессе),
сигнатура транзакции отсутствует, что вызывало срабатывание assert-проверки.
В результате рефакторинга и ряда оптимизаций для завершения/гашения
курсоров в читающих и пишущих транзакций стал использоваться общий код.
Причем за основу, был взят соответствующий фрагмент относящийся к
пишущим транзакциям, в которых пользователю не позволяется
использоваться курсоры для DBI=0 и поэтому эта итераций пропускалась.
В результате, при завершении читающих транзакциях, курсоры связанные с
DBI=0 не завершались должным образом, а при их повторном использовании
или явном закрытии после завершения читающей транзакции происходило
обращение к уже освобожденной памяти. Если же такие курсоры
отсоединялись или закрывались до завершения читающей транзакции, то
ошибка не имела шансов на проявление.
Спасибо Илье Михееву (https://github.com/JkLondon) и команде Erigon (https://erigon.tech) за сообщения о проблеме.
Исторически в 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, по аналогии обработки фиксации
аварийных пишущих транзакций.
Упомянутый флажок отсутствовал в пути разрушения транзакции при ошибке
её запуска. Из-за чего делалась попытка разрушить курсоры, что приводило
к падению отладочных сборок, так как в них соответствующий массив
намеренно заполнен некорректными указателями.
