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

tarantool / tarantool / 13837374380
87%
master: 88%

Build:
Build:
LAST BUILD BRANCH: ninarodicova/test5
DEFAULT BRANCH: master
Ran 13 Mar 2025 03:01PM UTC
Jobs 1
Files 514
Run time 75min
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

13 Mar 2025 02:34PM UTC coverage: 87.383% (-0.02%) from 87.399%
13837374380

push

github

locker
vinyl: fix space truncation being aborted by yield under load

Under the hood, `space:truncate()` calls `space_vtab::build_index` to
notify the engine about index recreation, see `TruncateIndex::prepare`.
`space_vtab::build_index` isn't supposed to yield in this case because
the space is empty (note that `TruncateIndex::prepare` passes the new
space to the callback). However, there's a bug in vinyl that makes this
callback yield for no good reason, aborting `space:truncate()` with
`ER_TRANSACTION_YIELD`.

The problem lies in `vy_tx_manager_abort_writers_for_ddl()`, which is
called by `vinyl_space_build_index()` to abort all transactions that
write to the target space. If a transaction can't be aborted because
it has reached WAL, the function sets the `need_wal_sync` flag which
indicates the caller that they should call `wal_sync()` to flush all
unconfirmed transactions. In case of a space truncation, the function
should do nothing because there can't possibly be a transaction writing
to the new space, but actually it sets `need_wal_sync` if there's any
transaction waiting for WAL. This mistake doesn't lead to any problems
during an actual index build, but in case of a space truncation it
results in the transaction being aborted by a fiber yield.

Let's fix this problem by setting the `need_wal_sync` flag only if
there are transactions that actually write to the target space.

Closes #11249

NO_DOC=bug fix

(cherry picked from commit b145c0c89)

68824 of 122061 branches covered (56.38%)

8 of 8 new or added lines in 1 file covered. (100.0%)

42 existing lines in 16 files now uncovered.

101503 of 116159 relevant lines covered (87.38%)

1958691.45 hits per line

Uncovered Existing Lines

Lines Coverage ∆ File
1
95.89
-0.05% src/box/iproto.cc
1
95.05
-0.31% src/box/raft.c
1
92.45
-0.47% src/box/recovery.cc
1
92.24
-0.05% src/box/vinyl.c
1
95.21
1.06% src/box/vy_range.c
1
80.0
-2.05% src/lib/core/clock.c
1
97.4
-0.06% src/lib/salad/bps_tree.h
1
91.45
0.0% src/lib/swim/swim.c
1
97.41
-0.86% src/lib/vclock/vclock.c
2
86.27
-0.48% src/box/vy_stmt.c
2
84.45
0.02% src/box/xlog.c
2
85.71
-9.52% src/lib/core/tt_sigaction.c
3
90.9
-0.31% src/box/vy_scheduler.c
3
92.93
-0.29% src/lib/core/fiber.c
4
90.7
-0.3% src/box/applier.cc
17
90.65
-0.56% src/box/box.cc
Jobs
ID Job ID Ran Files Coverage
1 13837374380.1 13 Mar 2025 03:02PM UTC 514
87.38
GitHub Action Run
Source Files on build 13837374380
  • Tree
  • List 514
  • Changed 25
  • Source Changed 0
  • Coverage Changed 25
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • 42d777e1 on github
  • Prev Build on release/3.2 (#13786135440)
  • Next Build on release/3.2 (#13931070088)
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