• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

tarantool / tarantool / 12392280108
86%
master: 88%

Build:
Build:
LAST BUILD BRANCH: backport/release/3.6/12152
DEFAULT BRANCH: master
Ran 18 Dec 2024 12:14PM UTC
Jobs 1
Files 479
Run time 2min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

18 Dec 2024 11:45AM UTC coverage: 85.966% (+0.03%) from 85.941%
12392280108

push

github

locker
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%)

17 existing lines in 6 files now uncovered.

94104 of 109466 relevant lines covered (85.97%)

2979180.15 hits per line

Jobs
ID Job ID Ran Files Coverage
1 12392280108.1 18 Dec 2024 12:14PM UTC 0
85.97
GitHub Action Run
Source Files on build 12392280108
Detailed source file information is not available for this build.
  • Back to Repo
  • 56f25f2d on github
  • Prev Build on release/2.11 (#12352796548)
  • Next Build on release/2.11 (#12469184863)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc