vinyl: fix cache invalidation on rollback of DELETE statement#10900
Merged
locker merged 3 commits intotarantool:masterfrom Dec 10, 2024
Merged
vinyl: fix cache invalidation on rollback of DELETE statement#10900locker merged 3 commits intotarantool:masterfrom
locker merged 3 commits intotarantool:masterfrom
Conversation
There's no point in doing so because if the committed tuple has been overwritten by the time it's committed, the statement that overwrote it must have already invalidated the cache, see `vy_tx_write()`. The code invalidating the cache on commit was added along with the cache implementation without any justification. NO_DOC=minor NO_TEST=minor NO_CHANGELOG=minor
vy_lsm.c seems to be a more appropriate place for cache invalidation because (a) it's vy_lsm that owns the cache and (b) we invalidate the cache on rollback in vy_lsm_rollback_stmt(). While we are at it, let's inline vy_tx_write() and vy_tx_write_prepare() because they are trivial and used in just one place. NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring
Once a statement is prepared to be committed to WAL, it becomes visible (in the 'read-committed' isolation level) so it can be added to the tuple cache. That's why if the statement is rolled back due to a WAL error, we have to invalidate the cache. The problem is that the function invalidating the cache (`vy_cache_on_write`) ignores the statement if it's a DELETE judging that "there was nothing and there is nothing now". This is apparently wrong for rollback. Fix it. Closes tarantool#10879 NO_DOC=bug fix
xuniq
approved these changes
Dec 10, 2024
Member
Author
|
Cherry-picked to 2.11, 3.2, 3.3. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Once a statement is prepared to be committed to WAL, it becomes visible (in the 'read-committed' isolation level) so it can be added to the tuple cache. That's why if the statement is rolled back due to a WAL error, we have to invalidate the cache. The problem is that the function invalidating the cache (
vy_cache_on_write) ignores the statement if it's a DELETE judging that "there was nothing and there is nothing now". This is apparently wrong for rollback. Fix it.While we are at it, let's also do a bit of related refactoring. It isn't necessary to fix the bug, but it should make the code more straightforward.
Closes #10879