mdbxmou 0.1.26

package/deps/libmdbx/docs/_preface.md

@@ -0,0 +1,47 @@
+\page intro Introduction
+\section characteristics Characteristics
+
+Preface {#preface}
+------------------
+
+> For the most part, this section is a copy of the corresponding text
+> from LMDB description, but with some edits reflecting the improvements
+> and enhancements were made in MDBX.
+
+MDBX is a Btree-based database management library modeled loosely on the
+BerkeleyDB API, but much simplified. The entire database (aka "environment")
+is exposed in a memory map, and all data fetches return data directly from
+the mapped memory, so no malloc's or memcpy's occur during data fetches.
+As such, the library is extremely simple because it requires no page caching
+layer of its own, and it is extremely high performance and memory-efficient.
+It is also fully transactional with full ACID semantics, and when the memory
+map is read-only, the database integrity cannot be corrupted by stray pointer
+writes from application code.
+
+The library is fully thread-aware and supports concurrent read/write access
+from multiple processes and threads. Data pages use a copy-on-write strategy
+so no active data pages are ever overwritten, which also provides resistance
+to corruption and eliminates the need of any special recovery procedures
+after a system crash. Writes are fully serialized; only one write transaction
+may be active at a time, which guarantees that writers can never deadlock.
+The database structure is multi-versioned so readers run with no locks;
+writers cannot block readers, and readers don't block writers.
+
+Unlike other well-known database mechanisms which use either write-ahead
+transaction logs or append-only data writes, MDBX requires no maintenance
+during operation. Both write-ahead loggers and append-only databases require
+periodic checkpointing and/or compaction of their log or database files
+otherwise they grow without bound. MDBX tracks retired/freed pages within the
+database and re-uses them for new write operations, so the database size does
+not grow without bound in normal use. It is worth noting that the "next"
+version libmdbx (\ref MithrilDB) will solve this problem.
+
+The memory map can be used as a read-only or read-write map. It is read-only
+by default as this provides total immunity to corruption. Using read-write
+mode offers much higher write performance, but adds the possibility for stray
+application writes thru pointers to silently corrupt the database.
+Of course if your application code is known to be bug-free (...) then this is
+not an issue.
+
+If this is your first time using a transactional embedded key-value store,
+you may find the \ref starting section below to be helpful.

package/deps/libmdbx/docs/_restrictions.md

@@ -0,0 +1,248 @@
+Restrictions & Caveats {#restrictions}
+======================
+In addition to those listed for some functions.
+
+
+## Long-lived read transactions {#long-lived-read}
+Avoid long-lived read transactions, especially in the scenarios with a
+high rate of write transactions. Long-lived read transactions prevents
+recycling pages retired/freed by newer write transactions, thus the
+database can grow quickly.
+
+Understanding the problem of long-lived read transactions requires some
+explanation, but can be difficult for quick perception. So is is
+reasonable to simplify this as follows:
+  1. Garbage collection problem exists in all databases one way or
+     another, e.g. VACUUM in PostgreSQL. But in MDBX it's even more
+     discernible because of high transaction rate and intentional
+     internals simplification in favor of performance.
+
+  2. MDBX employs [Multiversion concurrency control](https://en.wikipedia.org/wiki/Multiversion_concurrency_control)
+     on the [Copy-on-Write](https://en.wikipedia.org/wiki/Copy-on-write)
+     basis, that allows multiple readers runs in parallel with a write
+     transaction without blocking. An each write transaction needs free
+     pages to put the changed data, that pages will be placed in the new
+     b-tree snapshot at commit. MDBX efficiently recycling pages from
+     previous created unused snapshots, BUT this is impossible if anyone
+     a read transaction use such snapshot.
+
+  3. Thus massive altering of data during a parallel long read operation
+     will increase the process's work set and may exhaust entire free
+     database space.
+
+A good example of long readers is a hot backup to the slow destination
+or debugging of a client application while retaining an active read
+transaction. LMDB this results in `MDB_MAP_FULL` error and subsequent write
+performance degradation.
+
+MDBX mostly solve "long-lived" readers issue by offering to use a
+transaction parking-and-ousting approach by \ref mdbx_txn_park(),
+Handle-Slow-Readers \ref MDBX_hsr_func callback which allows to abort
+long-lived read transactions, and using the \ref MDBX_LIFORECLAIM mode
+which addresses subsequent performance degradation. The "next" version
+of libmdbx (aka \ref MithrilDB) will completely solve this.
+
+Nonetheless, situations that encourage lengthy read transactions while
+intensively updating data should be avoided. For example, you should
+avoid suspending/blocking processes/threads performing read
+transactions, including during debugging, and use transaction parking if
+necessary.
+
+You should also beware of aborting processes that perform reading
+transactions. Despite the fact that libmdbx automatically checks and
+cleans readers, as an a process aborting (especially with core dump) can
+take a long time, and checking readers cannot be performed too often due
+to performance degradation.
+
+This issue will be addressed in MithrlDB and one of libmdbx releases,
+presumably in 2025. To do this, nonlinear GC recycling will be
+implemented, without stopping garbage recycling on the old MVCC snapshot
+used by a long read transaction.
+
+After the planned implementation, any long-term reading transaction will
+still keep the used MVCC-snapshot (all the database pages forming it)
+from being recycled, but it will allow all unused MVCC snapshots to be
+recycled, both before and after the readable one. This will eliminate
+one of the main architectural flaws inherited from LMDB and caused the
+growth of a database in proportion to a volume of data changes made
+concurrently with a long-running read transaction.
+
+
+## Large data items
+
+MDBX allows you to store values up to 1 gigabyte in size, but this is
+not the main functionality for a key-value storage, but an additional
+feature that should not be abused. Such long values are stored in
+consecutive/adjacent DB pages, which has both pros and cons. This allows
+you to read long values directly without copying and without any
+overhead from a linear section of memory.
+
+On the other hand, when putting such values in the database, it is
+required to find a sufficient number of free consecutive/adjacent
+database pages, which can be very difficult and expensive, moreover
+sometimes impossible since b-tree tends to fragmentation. So, when
+placing very long values, the engine may need to process the entire GC,
+and in the absence of a sufficient sequence of free pages, increase the
+DB file. Thus, for long values, MDBX provides maximum read performance
+at the expense of write performance.
+
+Some aspects related to GC have been refined and improved in 2022 within
+the first releases of the 0.12.x series. In particular the search for
+free consecutive/adjacent pages through GC has been significantly
+speeded, including acceleration using NOEN/SSE2/AVX2/AVX512
+instructions.
+
+This issue will be addressed in MithrlDB and refined within one of
+0.15.x libmdbx releases, presumably at end of 2025.
+
+
+### Huge transactions
+
+A similar situation can be with huge transactions, in which a lot of
+database pages are retired. The retired pages should be put into GC as a
+list of page numbers for future reuse. But in huge transactions, such a
+list of retired page numbers can also be huge, i.e. it is a very long
+value and requires a long sequence of free pages to be saved. Thus, if
+you delete large amounts of information from the database in a single
+transaction, MDBX may need to increase the database file to save the
+list of pages to be retired.
+
+This issue was fixed in 2022 within the first releases of the 0.12.x
+series by `Big Foot` feature, which now is enabled by default.
+See \ref MDBX_ENABLE_BIGFOOT build-time option.
+
+The `Big Foot` feature which significantly reduces GC overhead for
+processing large lists of retired pages from huge transactions. Now
+libmdbx avoid creating large chunks of PNLs (page number lists) which
+required a long sequences of free pages, aka large/overflow pages. Thus
+avoiding searching, allocating and storing such sequences inside GC.
+
+
+## Space reservation
+An MDBX database configuration will often reserve considerable unused
+memory address space and maybe file size for future growth. This does
+not use actual memory or disk space, but users may need to understand
+the difference so they won't be scared off.
+
+However, on 64-bit systems with a relative small amount of RAM, such
+reservation can deplete system resources (trigger ENOMEM error, etc)
+when setting an inadequately large upper DB size using \ref
+mdbx_env_set_geometry() or \ref mdbx::env::geometry. So just avoid this.
+
+
+## Remote filesystems
+Do not use MDBX databases on remote filesystems, even between processes
+on the same host. This breaks file locks on some platforms, possibly
+memory map sync, and certainly sync between programs on different hosts.
+
+On the other hand, MDBX support the exclusive database operation over
+a network, and cooperative read-only access to the database placed on
+a read-only network shares.
+
+
+## Child processes
+Do not use opened \ref MDBX_env instance(s) in a child processes after `fork()`.
+It would be insane to call fork() and any MDBX-functions simultaneously
+from multiple threads. The best way is to prevent the presence of open
+MDBX-instances during `fork()`.
+
+The \ref MDBX_ENV_CHECKPID build-time option, which is ON by default on
+non-Windows platforms (i.e. where `fork()` is available), enables PID
+checking at a few critical points. But this does not give any guarantees,
+but only allows you to detect such errors a little sooner. Depending on
+the platform, you should expect an application crash and/or database
+corruption in such cases.
+
+On the other hand, MDBX allow calling \ref mdbx_env_close() in such cases to
+release resources, but no more and in general this is a wrong way.
+
+#### Since v0.13.1 and later
+
+Starting from the v0.13.1 release, the \ref mdbx_env_resurrect_after_fork()
+is available, which allows you to reuse an already open database
+environment in child processes, but strictly without inheriting any
+transactions from a parent process.
+
+
+## Read-only mode
+There is no pure read-only mode in a normal explicitly way, since
+readers need write access to LCK-file to be ones visible for writer.
+
+So MDBX always tries to open/create LCK-file for read-write, but switches
+to without-LCK mode on appropriate errors (`EROFS`, `EACCESS`, `EPERM`)
+if the read-only mode was requested by the \ref MDBX_RDONLY flag which is
+described below.
+
+
+## Troubleshooting the LCK-file
+1. A broken LCK-file can cause sync issues, including appearance of
+  wrong/inconsistent data for readers. When database opened in the
+  cooperative read-write mode the LCK-file requires to be mapped to
+  memory in read-write access. In this case it is always possible for
+  stray/malfunctioned application could writes thru pointers to
+  silently corrupt the LCK-file.
+
+  Unfortunately, there is no any portable way to prevent such
+  corruption, since the LCK-file is updated concurrently by
+  multiple processes in a lock-free manner and any locking is
+  unwise due to a large overhead.
+
+  \note Workaround: Just make all programs using the database close it;
+  the LCK-file is always reset on first open.
+
+2. Stale reader transactions left behind by an aborted program cause
+  further writes to grow the database quickly, and stale locks can
+  block further operation.
+  MDBX checks for stale readers while opening environment and before
+  growth the database. But in some cases, this may not be enough.
+
+  \note Workaround: Check for stale readers periodically, using the
+  \ref mdbx_reader_check() function or the mdbx_stat tool.
+
+3. Stale writers will be cleared automatically by MDBX on supported
+  platforms. But this is platform-specific, especially of
+  implementation of shared POSIX-mutexes and support for robust
+  mutexes. For instance there are no known issues on Linux, OSX,
+  Windows and FreeBSD.
+
+  \note Workaround: Otherwise just make all programs using the database
+  close it; the LCK-file is always reset on first open of the environment.
+
+
+## One thread - One transaction
+A thread can only use one transaction at a time, plus any nested
+read-write transactions in the non-writemap mode. Each transaction
+belongs to one thread. The \ref MDBX_NOSTICKYTHREADS flag changes this,
+see below.
+
+Do not start more than one transaction for a one thread. If you think
+about this, it's really strange to do something with two data snapshots
+at once, which may be different. MDBX checks and preventing this by
+returning corresponding error code (\ref MDBX_TXN_OVERLAPPING,
+\ref MDBX_BAD_RSLOT, \ref MDBX_BUSY) unless you using
+\ref MDBX_NOSTICKYTHREADS option on the environment.
+Nonetheless, with the `MDBX_NOSTICKYTHREADS` option, you must know
+exactly what you are doing, otherwise you will get deadlocks or reading
+an alien data.
+
+
+## Do not open twice
+Do not have open an MDBX database twice in the same process at the same
+time. By default MDBX prevent this in most cases by tracking databases
+opening and return \ref MDBX_BUSY if anyone LCK-file is already open.
+
+The reason for this is that when the "Open file description" locks (aka
+OFD-locks) are not available, MDBX uses POSIX locks on files, and these
+locks have issues if one process opens a file multiple times. If a single
+process opens the same environment multiple times, closing it once will
+remove all the locks held on it, and the other instances will be
+vulnerable to corruption from other processes.
+
+For compatibility with LMDB which allows multi-opening, MDBX can be
+configured at runtime by `mdbx_setup_debug(MDBX_DBG_LEGACY_MULTIOPEN, ...)`
+prior to calling other MDBX functions. In this way MDBX will track
+databases opening, detect multi-opening cases and then recover POSIX file
+locks as necessary. However, lock recovery can cause unexpected pauses,
+such as when another process opened the database in exclusive mode before
+the lock was restored - we have to wait until such a process releases the
+database, and so on.

package/deps/libmdbx/docs/_starting.md

@@ -0,0 +1,245 @@
+Getting started {#starting}
+===============
+
+> This section is based on Bert Hubert's intro "LMDB Semantics", with
+> edits reflecting the improvements and enhancements were made in MDBX.
+> See Bert Hubert's [original](https://github.com/ahupowerdns/ahutils/blob/master/lmdb-semantics.md).
+
+Everything starts with an environment, created by \ref mdbx_env_create().
+Once created, this environment must also be opened with \ref mdbx_env_open(),
+and after use be closed by \ref mdbx_env_close(). At that a non-zero value
+of the last argument "mode" supposes MDBX will create database and directory
+if ones does not exist. In this case the non-zero "mode" argument specifies
+the file mode bits be applied when a new files are created by `open()` function.
+
+Within that directory, a lock file (aka LCK-file) and a storage file (aka
+DXB-file) will be generated. If you don't want to use a directory, you can
+pass the \ref MDBX_NOSUBDIR option, in which case the path you provided is used
+directly as the DXB-file, and another file with a "-lck" suffix added
+will be used for the LCK-file.
+
+Once the environment is open, a transaction can be created within it using
+\ref mdbx_txn_begin(). Transactions may be read-write or read-only, and read-write
+transactions may be nested. A transaction must only be used by one thread at
+a time. Transactions are always required, even for read-only access. The
+transaction provides a consistent view of the data.
+
+Once a transaction has been created, a database (i.e. key-value space inside
+the environment) can be opened within it using \ref mdbx_dbi_open(). If only one
+database will ever be used in the environment, a `NULL` can be passed as the
+database name. For named databases, the \ref MDBX_CREATE flag must be used to
+create the database if it doesn't already exist. Also, \ref mdbx_env_set_maxdbs()
+must be called after \ref mdbx_env_create() and before \ref mdbx_env_open() to set
+the maximum number of named databases you want to support.
+
+\note A single transaction can open multiple databases. Generally databases
+should only be opened once, by the first transaction in the process.
+
+Within a transaction, \ref mdbx_get() and \ref mdbx_put() can store single key-value
+pairs if that is all you need to do (but see \ref Cursors below if you want to do
+more).
+
+A key-value pair is expressed as two \ref MDBX_val structures. This struct that is
+exactly similar to POSIX's `struct iovec` and has two fields, `iov_len` and
+`iov_base`. The data is a `void` pointer to an array of `iov_len` bytes.
+\note The notable difference between MDBX and LMDB is that MDBX support zero
+length keys.
+
+Because MDBX is very efficient (and usually zero-copy), the data returned in
+an \ref MDBX_val structure may be memory-mapped straight from disk. In other words
+look but do not touch (or `free()` for that matter). Once a transaction is
+closed, the values can no longer be used, so make a copy if you need to keep
+them after that.
+
+## Cursors {#Cursors}
+To do more powerful things, we must use a cursor.
+
+Within the transaction, a cursor can be created with \ref mdbx_cursor_open().
+With this cursor we can store/retrieve/delete (multiple) values using
+\ref mdbx_cursor_get(), \ref mdbx_cursor_put() and \ref mdbx_cursor_del().
+
+The \ref mdbx_cursor_get() positions itself depending on the cursor operation
+requested, and for some operations, on the supplied key. For example, to list
+all key-value pairs in a database, use operation \ref MDBX_FIRST for the first
+call to \ref mdbx_cursor_get(), and \ref MDBX_NEXT on subsequent calls, until
+the end is hit.
+
+To retrieve all keys starting from a specified key value, use \ref MDBX_SET. For
+more cursor operations, see the \ref c_api reference.
+
+When using \ref mdbx_cursor_put(), either the function will position the cursor
+for you based on the key, or you can use operation \ref MDBX_CURRENT to use the
+current position of the cursor. \note Note that key must then match the current
+position's key.
+
+
+## Summarizing the opening
+
+So we have a cursor in a transaction which opened a database in an
+environment which is opened from a filesystem after it was separately
+created.
+
+Or, we create an environment, open it from a filesystem, create a transaction
+within it, open a database within that transaction, and create a cursor
+within all of the above.
+
+Got it?
+
+
+## Threads and processes
+
+Do not have open an database twice in the same process at the same time, MDBX
+will track and prevent this. Instead, share the MDBX environment that has
+opened the file across all threads. The reason for this is:
+ - When the "Open file description" locks (aka OFD-locks) are not available,
+   MDBX uses POSIX locks on files, and these locks have issues if one process
+   opens a file multiple times.
+ - If a single process opens the same environment multiple times, closing it
+   once will remove all the locks held on it, and the other instances will be
+   vulnerable to corruption from other processes.
+ + For compatibility with LMDB which allows multi-opening, MDBX can be
+   configured at runtime by \ref mdbx_setup_debug() with \ref MDBX_DBG_LEGACY_MULTIOPEN` option
+   prior to calling other MDBX functions. In this way MDBX will track
+   databases opening, detect multi-opening cases and then recover POSIX file
+   locks as necessary. However, lock recovery can cause unexpected pauses,
+   such as when another process opened the database in exclusive mode before
+   the lock was restored - we have to wait until such a process releases the
+   database, and so on.
+
+Do not use opened MDBX environment(s) after `fork()` in a child process(es),
+MDBX will check and prevent this at critical points. Instead, ensure there is
+no open MDBX-instance(s) during fork(), or at least close it immediately after
+`fork()` in the child process and reopen if required - for instance by using
+`pthread_atfork()`. The reason for this is:
+ - For competitive consistent reading, MDBX assigns a slot in the shared
+   table for each process that interacts with the database. This slot is
+   populated with process attributes, including the PID.
+ - After `fork()`, in order to remain connected to a database, the child
+   process must have its own such "slot", which can't be assigned in any
+   simple and robust way another than the regular.
+ - A write transaction from a parent process cannot continue in a child
+   process for obvious reasons.
+ - Moreover, in a multithreaded process at the fork() moment any number of
+   threads could run in critical and/or intermediate sections of MDBX code
+   with interaction and/or racing conditions with threads from other
+   process(es). For instance: shrinking a database or copying it to a pipe,
+   opening or closing environment, beginning or finishing a transaction,
+   and so on.
+ = Therefore, any solution other than simply close database (and reopen if
+   necessary) in a child process would be both extreme complicated and so
+   fragile.
+
+Do not start more than one transaction for a one thread. If you think
+about this, it's really strange to do something with two data snapshots
+at once, which may be different. MDBX checks and preventing this by
+returning corresponding error code (\ref MDBX_TXN_OVERLAPPING,
+\ref MDBX_BAD_RSLOT, \ref MDBX_BUSY) unless you using
+\ref MDBX_NOSTICKYTHREADS option on the environment. Nonetheless,
+with the \ref MDBX_NOSTICKYTHREADS option, you must know exactly what
+you are doing, otherwise you will get deadlocks or reading an alien
+data.
+
+Also note that a transaction is tied to one thread by default using
+Thread Local Storage. If you want to pass transactions across threads,
+you can use the \ref MDBX_NOSTICKYTHREADS option on the environment.
+Nevertheless, a write transaction must be committed or aborted in the
+same thread which it was started. MDBX checks this in a reasonable
+manner and return the \ref MDBX_THREAD_MISMATCH error in rules
+violation.
+
+
+## Transactions, rollbacks etc
+
+To actually get anything done, a transaction must be committed using
+\ref mdbx_txn_commit(). Alternatively, all of a transaction's operations
+can be discarded using \ref mdbx_txn_abort().
+
+\attention An important difference between MDBX and LMDB is that MDBX required
+that any opened cursors can be reused and must be freed explicitly, regardless
+ones was opened in a read-only or write transaction. The REASON for this is
+eliminates ambiguity which helps to avoid errors such as: use-after-free,
+double-free, i.e. memory corruption and segfaults.
+
+For read-only transactions, obviously there is nothing to commit to storage.
+\attention An another notable difference between MDBX and LMDB is that MDBX make
+handles opened for existing databases immediately available for other
+transactions, regardless this transaction will be aborted or reset. The
+REASON for this is to avoiding the requirement for multiple opening a same
+handles in concurrent read transactions, and tracking of such open but hidden
+handles until the completion of read transactions which opened them.
+
+In addition, as long as a transaction is open, a consistent view of the
+database is kept alive, which requires storage. A read-only transaction that
+no longer requires this consistent view should be terminated (committed or
+aborted) when the view is no longer needed (but see below for an
+optimization).
+
+There can be multiple simultaneously active read-only transactions but only
+one that can write. Once a single read-write transaction is opened, all
+further attempts to begin one will block until the first one is committed or
+aborted. This has no effect on read-only transactions, however, and they may
+continue to be opened at any time.
+
+
+## Duplicate keys aka Multi-values
+
+\ref mdbx_get() and \ref mdbx_put() respectively have no and only some support or
+multiple key-value pairs with identical keys. If there are multiple values
+for a key, \ref mdbx_get() will only return the first value.
+
+When multiple values for one key are required, pass the \ref MDBX_DUPSORT flag to
+\ref mdbx_dbi_open(). In an \ref MDBX_DUPSORT database, by default \ref mdbx_put() will
+not replace the value for a key if the key existed already. Instead it will add
+the new value to the key. In addition, \ref mdbx_del() will pay attention to the
+value field too, allowing for specific values of a key to be deleted.
+
+Finally, additional cursor operations become available for traversing through
+and retrieving duplicate values.
+
+
+## Some optimization
+
+If you frequently begin and abort read-only transactions, as an optimization,
+it is possible to only reset and renew a transaction.
+
+\ref mdbx_txn_reset() releases any old copies of data kept around for a read-only
+transaction. To reuse this reset transaction, call \ref mdbx_txn_renew() on it.
+Any cursors in this transaction can also be renewed using \ref mdbx_cursor_renew()
+or freed by \ref mdbx_cursor_close().
+
+To permanently free a transaction, reset or not, use \ref mdbx_txn_abort().
+
+
+## Cleaning up
+
+Any created cursors must be closed using \ref mdbx_cursor_close(). It is advisable
+to repeat:
+\note An important difference between MDBX and LMDB is that MDBX required that
+any opened cursors can be reused and must be freed explicitly, regardless
+ones was opened in a read-only or write transaction. The REASON for this is
+eliminates ambiguity which helps to avoid errors such as: use-after-free,
+double-free, i.e. memory corruption and segfaults.
+
+It is very rarely necessary to close a database handle, and in general they
+should just be left open. When you close a handle, it immediately becomes
+unavailable for all transactions in the environment. Therefore, you should
+avoid closing the handle while at least one transaction is using it.
+
+
+## Now read up on the full API!
+
+The full \ref c_api documentation lists further details below, like how to:
+
+- Configure database size and automatic size management: \ref mdbx_env_set_geometry().
+- Drop and clean a database: \ref mdbx_drop().
+- Detect and report errors: \ref c_err.
+- Optimize (bulk) loading speed: \ref MDBX_MULTIPLE, \ref MDBX_APPEND.
+- Reduce (temporarily) robustness to gain even more speed: \ref sync_modes.
+- Gather statistics about the database: \ref c_statinfo.
+- Sstimate size of range query result: \ref c_rqest.
+- Double performance by LIFO reclaiming on storages with write-back: \ref MDBX_LIFORECLAIM.
+- Use sequences and canary markers: \ref mdbx_dbi_sequence(), \ref MDBX_canary.
+- Use Handle-Slow-Readers callback to resolve a database full/overflow issues
+  due to long-lived read transactions: \ref mdbx_env_set_hsr().
+- Use exclusive mode: \ref MDBX_EXCLUSIVE.
+- Define custom sort orders (but this is recommended to be avoided).

package/deps/libmdbx/docs/_toc.md

@@ -0,0 +1,34 @@
+The source code is availale on [Gitflic](https://gitflic.ru/project/erthink/libmdbx) and mirrors on [abf.io](https://abf.io/erthink/libmdbx), [hub.mos.ru](https://hub.mos.ru/leo/libmdbx) and [Github](https://github.com/erthink/libmdbx).
+Donations are welcome to ETH `0xD104d8f8B2dC312aaD74899F83EBf3EEBDC1EA3A`.
+Всё будет хорошо!
+
+> Questions, feedback and suggestions are welcome to the [Telegram' group](https://t.me/libmdbx).
+
+\section toc Table of Contents
+
+This manual is divided into parts,
+each of which is divided into several sections.
+
+1. The \ref intro
+  - \ref characteristics
+  - \ref improvements
+  - \ref restrictions
+  - \ref performance
+2. \ref usage
+  - \ref getting
+  - \ref starting
+  - \ref bindings
+
+3. The `C/C++` API manual:
+  - The \ref c_api reference
+  - \ref c_crud_hints "Quick reference for Insert/Update/Delete operations"
+  - The \ref mdbx.h header file reference
+  - The \ref cxx_api reference
+  - The \ref mdbx.h++ header file reference
+
+Please do not hesitate to point out errors in the documentation,
+including creating [merge-request](https://gitflic.ru/project/erthink/libmdbx/merge-request) with corrections and improvements.
+
+---
+
+\section MithrilDB MithrilDB and Future

package/deps/libmdbx/docs/header.html

@@ -0,0 +1,96 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="$langISO">
+<head>
+<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
+<meta http-equiv="X-UA-Compatible" content="IE=11"/>
+<meta name="generator" content="Doxygen $doxygenversion"/>
+<meta name="viewport" content="width=device-width, initial-scale=1"/>
+<!--BEGIN PROJECT_NAME--><title>$projectname: $title</title><!--END PROJECT_NAME-->
+<!--BEGIN !PROJECT_NAME--><title>$title</title><!--END !PROJECT_NAME-->
+<!--BEGIN PROJECT_ICON-->
+<link rel="icon" href="$relpath^$projecticon" type="image/x-icon" />
+<!--END PROJECT_ICON-->
+<link href="$relpath^tabs.css" rel="stylesheet" type="text/css"/>
+<!--BEGIN DISABLE_INDEX-->
+  <!--BEGIN FULL_SIDEBAR-->
+<script type="text/javascript">var page_layout=1;</script>
+  <!--END FULL_SIDEBAR-->
+<!--END DISABLE_INDEX-->
+<script type="text/javascript" src="$relpath^jquery.js"></script>
+<script type="text/javascript" src="$relpath^dynsections.js"></script>
+<!--BEGIN COPY_CLIPBOARD-->
+<script type="text/javascript" src="$relpath^clipboard.js"></script>
+<!--END COPY_CLIPBOARD-->
+$treeview
+$search
+$mathjax
+$darkmode
+<link href="$relpath^$stylesheet" rel="stylesheet" type="text/css" />
+$extrastylesheet
+</head>
+<body>
+<!--BEGIN DISABLE_INDEX-->
+  <!--BEGIN FULL_SIDEBAR-->
+<div id="side-nav" class="ui-resizable side-nav-resizable"><!-- do not remove this div, it is closed by doxygen! -->
+  <!--END FULL_SIDEBAR-->
+<!--END DISABLE_INDEX-->
+
+<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
+
+<!--BEGIN TITLEAREA-->
+<div id="titlearea">
+<table cellspacing="0" cellpadding="0">
+ <tbody>
+ <tr id="projectrow">
+  <!--BEGIN PROJECT_LOGO-->
+  <td id="projectlogo"><img alt="Logo" src="$relpath^$projectlogo"$logosize/></td>
+  <!--END PROJECT_LOGO-->
+  <!--BEGIN PROJECT_NAME-->
+  <td id="projectalign">
+   <div id="projectname">$projectname<!--BEGIN PROJECT_NUMBER--><span id="projectnumber">&#160;$projectnumber</span><!--END PROJECT_NUMBER-->
+   </div>
+   <!--BEGIN PROJECT_BRIEF--><div id="projectbrief">$projectbrief</div><!--END PROJECT_BRIEF-->
+  </td>
+  <!--END PROJECT_NAME-->
+  <!--BEGIN !PROJECT_NAME-->
+   <!--BEGIN PROJECT_BRIEF-->
+    <td>
+    <div id="projectbrief">$projectbrief</div>
+    </td>
+   <!--END PROJECT_BRIEF-->
+  <!--END !PROJECT_NAME-->
+  <!--BEGIN DISABLE_INDEX-->
+   <!--BEGIN SEARCHENGINE-->
+     <!--BEGIN !FULL_SIDEBAR-->
+    <td>$searchbox</td>
+     <!--END !FULL_SIDEBAR-->
+   <!--END SEARCHENGINE-->
+  <!--END DISABLE_INDEX-->
+ </tr>
+  <!--BEGIN SEARCHENGINE-->
+   <!--BEGIN FULL_SIDEBAR-->
+   <tr><td colspan="2">$searchbox</td></tr>
+   <!--END FULL_SIDEBAR-->
+  <!--END SEARCHENGINE-->
+ </tbody>
+</table>
+</div>
+<!--END TITLEAREA-->
+<!-- Yandex.Metrika counter -->
+<script type="text/javascript" >
+   (function(m,e,t,r,i,k,a){m[i]=m[i]||function(){(m[i].a=m[i].a||[]).push(arguments)};
+   m[i].l=1*new Date();
+   for (var j = 0; j < document.scripts.length; j++) {if (document.scripts[j].src === r) { return; }}
+   k=e.createElement(t),a=e.getElementsByTagName(t)[0],k.async=1,k.src=r,a.parentNode.insertBefore(k,a)})
+   (window, document, "script", "https://mc.yandex.ru/metrika/tag.js", "ym");
+
+   ym(99261645, "init", {
+        clickmap:true,
+        trackLinks:true,
+        accurateTrackBounce:true,
+        webvisor:true
+   });
+</script>
+<noscript><div><img src="https://mc.yandex.ru/watch/99261645" style="position:absolute; left:-9999px;" alt="" /></div></noscript>
+<!-- /Yandex.Metrika counter -->
+<!-- end header part -->