Skip to content

vinyl: fix bugs in read iterator#10122

Merged
locker merged 2 commits intotarantool:masterfrom
locker:vy-read-iterator-fix
Jun 13, 2024
Merged

vinyl: fix bugs in read iterator#10122
locker merged 2 commits intotarantool:masterfrom
locker:vy-read-iterator-fix

Conversation

@locker
Copy link
Member

@locker locker commented Jun 10, 2024

The PR fixes a couple of bugs in the read iterator because of which tuples written to the database could be skipped by a range select.

Closes #10109

@locker locker requested a review from a team as a code owner June 10, 2024 11:24
@locker locker requested a review from nshy June 10, 2024 11:39
@coveralls
Copy link

Coverage Status

coverage: 87.096% (+0.02%) from 87.08%
when pulling d976512 on locker:vy-read-iterator-fix
into 530aa82
on tarantool:master
.

Copy link
Contributor

@nshy nshy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

locker added 2 commits June 11, 2024 15:46
If a run iterator is positioned at a non-terminal statement (UPSERT or
UPDATE), `vy_run_iterator_next()` will iterate over older statements
with the same key using `vy_run_iterator_next_lsn()` to build the key
history. While doing so, it may reach the end of the run file (if the
current key is the last in the run). This would stop iteration
permanently, which is apparently wrong for reverse iterators (LE or LT):
if this happens the run iterator won't return any keys preceding the
last one in the run file. Fix this by removing `vy_run_iterator_stop()`
from `vy_run_iterator_next_lsn()`.

Part of tarantool#10109

NO_DOC=bug fix
NO_CHANGELOG=next commit
The tuple cache doesn't store older tuple versions so if a reader is
in a read view, it must skip tuples that are newer than the read view,
see `vy_cache_iterator_stmt_is_visible()`. A reader must also ignore
cached intervals if any of the tuples used as a boundary is invisible
from the read view, see `vy_cache_iterator_skip_to_read_view()`.
There's a bug in `vy_cache_iterator_restore()` because of which such
an interval may be returned to the reader: when we step backwards
from the last returned tuple we consider only one of the boundaries.
As a result, if the other boundary is invisible from the read view,
the reader will assume there's nothing in the index between the
boundaries and skip reading older sources (memory, disk). Fix this by
always checking if the other boundary is visible.

Closes tarantool#10109

NO_DOC=bug fix
@locker locker force-pushed the vy-read-iterator-fix branch from d976512 to 7c7afd8 Compare June 11, 2024 12:47
@locker locker assigned locker and unassigned nshy Jun 11, 2024
@coveralls
Copy link

Coverage Status

coverage: 87.112% (+0.002%) from 87.11%
when pulling 7c7afd8 on locker:vy-read-iterator-fix
into 9b63ced
on tarantool:master
.

@locker locker added the full-ci Enables all tests for a pull request label Jun 11, 2024
@locker locker merged commit 7b72080 into tarantool:master Jun 13, 2024
@locker locker deleted the vy-read-iterator-fix branch June 13, 2024 07:25
@locker
Copy link
Member Author

locker commented Jun 13, 2024

Cherry-picked to 2.11 and 3.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

full-ci Enables all tests for a pull request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

tarantool: ./src/box/vy_read_iterator.c:617: vy_read_iterator_advance: Assertion `vy_read_iterator_cmp_stmt(itr, next, itr->last) > 0' failed.

4 participants