tarantool / tarantool / 12392280108

push

github

small: bump version

A long time ago the it's been found that in some circumstances the
RTREE index could fail to rollback because of OOM. This is the case
because removal of a key from such an index can sometimes lead to
allocation of new blocks that could fail. So, in order to guarantee
a successful rollback of an insertion into the index, the memtx
engine extent reservation machinery had been introduced (see the
issue #727).

But some time ago it's beed found out that the reservation of memory
prior to insertion can be not enough to guarantee a successful roll
back of the statements, so it's been decided to use a regular malloc
for failed allocations performed during rollback (see #10551). This
also fixed the RTREE issue for which the extent reservation had been
introduced in the first place.

But this functionality allows to simplify code of data structures,
such as BPS tree, so that we can reserve the max amount of extents
that could be required to perform an operation and, if reservation
succeeds, be sure that we're safe from any kind of OOM up until we
have finished the operation.

But it's only known to specific data structures which amount of memory
will be required for them to perform their operations, and all current
memtx structures (BPS tree, light hash, rtree, bitset) use matras to
deal with memory allocations, so it would be nice to make them able to
reserve exactly as much extents as they need themselves instead of
reserving max sane amount of ones as it's done now (see the constants:
`RESERVE_EXTENTS_BEFORE_REPLACE` and `RESERVE_EXTENTS_BEFORE_DELETE`).

The problem is that if we reserve extents in each matras instance we
will possibly be wasting a lot of memory in each index, so it would
be much better to share the reserved extents as it's done in the memtx
engine now.

So, in order to allow indexes reserve memoy for themselves and share
the reserved memory amoug all indexes, let's introduce a new entity:
`matras_allocator`.

The ent... (continued)

63251 of 114505 branches covered (55.24%)

32 of 33 new or added lines in 11 files covered. (96.97%)

94104 of 109466 relevant lines covered (85.97%)

2979180.15 hits per line