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

tarantool / tarantool / 13136102530
88%

Build:
DEFAULT BRANCH: master
Ran 04 Feb 2025 01:23PM UTC
Jobs 1
Files 518
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

04 Feb 2025 01:04PM UTC coverage: 87.375% (-0.009%) from 87.384%
13136102530

push

github

locker
memtx: finalize prepare of all transactions in memtx MVCC

We have a special `sysview` engine that bypasses transaction management
and reads right from memtx indexes. The problem is memtx indexes use
memtx MVCC by themselves, so despite `sysview` bypasses transaction
management process, it actually uses memtx MVCC. So the problem here is
that transaction can actually read something using `sysview`, a tracker
in MVCC will be allocated, but `txn->engine[memtx->id]` still will be
`NULL`, so the preparation of the transaction won't be finalized by
memtx_tx and the tracker won't be deleted when transaction is prepared.
On conflict, MVCC will try to abort that already prepared transaction
and it will lead to a crash.

Actually, crashing scenarios are rather synthetic and break only our
engine fuzzer. Here is an example of such scenario without manual use
of system spaces:
1. Open a transaction and do an operation in a vinyl space.
2. Try to alter the space in the same transaction - it will fail with
   cross-engine transaction error.
3. Commit the transaction, but do not wait for WAL write (internally,
   such state is called `prepared`).
4. Alter the space in another transaction and commit it before the
   previous transaction was written to WAL. Here MVCC will try to
   conflict that already prepared transaction and it will break
   Tarantool.

To solve the problem, we could try to write quite a large patch to handle
such transactions differently in memtx MVCC. But instead, let's simply
finalize prepare of all transaction in MVCC. The current design already
lacks encapsulation - all transactions (even non-memtx) are registered
there, so such solution not only simple but also consistent with other
MVCC parts. Note that memtx MVCC still can abort such non-memtx
transactions when they are in-progress, but it seems that such behavior
doesn't break other yielding engines (`vinyl` is the only one) - the
commit covers it with a simple test along the way.

In ord... (continued)

69711 of 123226 branches covered (56.57%)

6 of 6 new or added lines in 3 files covered. (100.0%)

37 existing lines in 10 files now uncovered.

102692 of 117530 relevant lines covered (87.38%)

2420511.96 hits per line

Uncovered Existing Lines

Lines Coverage ∆ File
1
84.27
-0.07% src/box/xlog.c
1
91.24
0.21% src/box/vy_scheduler.c
2
95.9
0.0% src/lib/msgpuck/msgpuck.h
2
87.54
-0.08% src/box/vy_run.c
2
85.71
-9.52% src/lib/core/tt_sigaction.c
3
97.95
-0.22% src/box/memtx_tx.c
3
93.03
-0.2% src/lib/core/fiber.c
3
92.19
-0.05% src/box/vinyl.c
3
91.59
-0.59% src/box/gc.c
17
90.91
-0.54% src/box/box.cc
Jobs
ID Job ID Ran Files Coverage
1 13136102530.1 04 Feb 2025 01:23PM UTC 518
87.38
GitHub Action Run
Source Files on build 13136102530
  • Tree
  • List 518
  • Changed 430
  • Source Changed 0
  • Coverage Changed 25
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • a217b0f5 on github
  • Prev Build on master (#13136060707)
  • Next Build on master (#13152495130)
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