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

tarantool / tarantool / 13136160889
88%
master: 88%

Build:
Build:
LAST BUILD BRANCH: fix-test-dir-for-gitlab-ci
DEFAULT BRANCH: master
Ran 04 Feb 2025 01:41PM 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:05PM UTC coverage: 87.38% (-0.01%) from 87.391%
13136160889

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)

69725 of 123584 branches covered (56.42%)

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

43 existing lines in 11 files now uncovered.

102689 of 117520 relevant lines covered (87.38%)

2480012.44 hits per line

Uncovered Existing Lines

Lines Coverage ∆ File
1
87.5
-1.59% src/box/xlog.h
1
95.36
-0.31% src/box/raft.c
1
74.81
-0.25% src/main.cc
1
89.64
-0.18% src/box/wal.c
2
84.35
-0.11% src/box/xlog.c
2
93.87
-0.39% src/box/xrow_update_field.c
2
84.62
-0.33% src/lib/core/say.c
4
93.31
-1.27% src/lib/swim/swim_io.c
5
89.05
-0.39% src/box/vy_log.c
8
60.84
-3.13% src/lib/core/fio.c
16
90.87
-0.45% src/box/box.cc
Jobs
ID Job ID Ran Files Coverage
1 13136160889.1 04 Feb 2025 01:41PM UTC 518
87.38
GitHub Action Run
Source Files on build 13136160889
  • Tree
  • List 518
  • Changed 457
  • Source Changed 0
  • Coverage Changed 29
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • 1f3aaa00 on github
  • Prev Build on release/3.3 (#13130778401)
  • Next Build on release/3.3 (#13152516707)
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