src/box/vy_cache.c:487: void vy_cache_on_write(struct vy_cache *, struct vy_entry, struct vy_entry *): Assertion `(*next_node)->flags & VY_CACHE_LEFT_LINKED' failed. #10879
Assignees
Comments
|
@ligurio Do you have a core dump? |
No. |
|
Cache invalidation on transaction rollback caused by a WAL write error seems to be broken for DELETE statements. Note, if there's a cache chain that was created after the rolled back DELETE statement was prepared, it won't be broken. Lines 1029 to 1037 in bca9265 Lines 458 to 461 in bca9265 Below is a script that should trigger the same assertion failure: It isn't a 100% reproducer though - that's why test function is called 100 times in a loop. reproducer.luaos.execute('rm -rf [0-9]*')
local fiber = require('fiber')
box.cfg{log_level = 'warn'}
local function test()
local s = box.schema.space.create('test', {engine = 'vinyl'})
s:create_index('primary')
s:insert({10})
s:insert({20})
s:insert({30})
box.snapshot()
box.error.injection.set('ERRINJ_WAL_DELAY', true)
fiber.new(function()
s:delete({20})
end)
fiber.new(function()
box.begin()
s:replace({2})
s:get({20})
box.rollback()
end)
fiber.new(function()
box.begin()
s:replace({1})
s:select({}, {iterator = 'ge', fullscan = true})
box.rollback()
end)
box.error.injection.set('ERRINJ_WAL_WRITE', true)
box.error.injection.set('ERRINJ_WAL_DELAY', false)
fiber.sleep(0.1)
box.error.injection.set('ERRINJ_WAL_WRITE', false)
s:select({10}, {iterator = 'ge', fullscan = true})
s:get({20})
s:replace({10})
s:drop()
end
for i = 1, 100 do
test()
end
os.exit(0) |
locker
added a commit
to locker/tarantool
that referenced
this issue
Dec 5, 2024
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
locker
added a commit
that referenced
this issue
Dec 10, 2024
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 #10879 NO_DOC=bug fix
locker
added a commit
that referenced
this issue
Dec 10, 2024
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 #10879 NO_DOC=bug fix (cherry picked from commit d64e29d)
locker
added a commit
that referenced
this issue
Dec 10, 2024
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 #10879 NO_DOC=bug fix (cherry picked from commit d64e29d)
locker
added a commit
that referenced
this issue
Dec 10, 2024
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 #10879 NO_DOC=bug fix (cherry picked from commit d64e29d)
picodata-account
pushed a commit
to picodata/tarantool
that referenced
this issue
Dec 11, 2024
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 (cherry picked from commit d64e29d)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug description
Tarantool 3.3.0-entrypoint-290-gd26f574f8d
Target: Linux-x86_64-Debug
Build options: cmake . -DCMAKE_INSTALL_PREFIX=/usr/local -DENABLE_BACKTRACE=TRUE
Compiler: Clang-18.1.3
C_FLAGS: -fexceptions -funwind-tables -fasynchronous-unwind-tables -fno-common -msse2 -fsanitize=address -Wformat -Wformat-security -Werror=format-security -fstack-protector-strong -fPIC -fmacro-prefix-map=/home/ubuntu/tarantool=. -std=c11 -Wall -Wextra -Wno-gnu-alignof-expression -Wno-cast-function-type -Werror -g -ggdb -O0
CXX_FLAGS: -fexceptions -funwind-tables -fasynchronous-unwind-tables -fno-common -msse2 -fsanitize=address -Wformat -Wformat-security -Werror=format-security -fstack-protector-strong -fPIC -fmacro-prefix-map=/home/ubuntu/tarantool=. -std=c++11 -Wall -Wextra -Wno-invalid-offsetof -Wno-gnu-alignof-expression -Wno-cast-function-type -Werror -g -ggdb -O0
Steps to reproduce
Actual behavior
Full log and tarantool binary: gh-10879.zip
Expected behavior
no assertion violation
The text was updated successfully, but these errors were encountered: