-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vinyl: Assertion `lsm->space_id == current_space_id'
is triggered
#10026
Comments
locker
added a commit
to locker/tarantool
that referenced
this issue
May 17, 2024
Like UPDATE, UPSERT must not modify primary key parts. Unlike UPDATE, such an invalid UPSERT statement doesn't fail (raise an error) - we just log the error and ignore the statement. The problem is, we don't clear txn_stmt. As a result, if we're currently building a new index, the on_replace trigger installed by the build procedure will try to process this statement, triggerring the assertion in the transaction manager that doesn't expect any statements in a secondary index without the corresponding statement in the primary index: ./src/box/vy_tx.c:728: vy_tx_prepare: Assertion `lsm->space_id == current_space_id' failed. Let's fix this by clearing the txn_stmt corresponding to a skipped UPSERT. Note, this also means that on_replace triggers installed by the user won't run on invalid UPSERT (hence test/vinyl/on_replace.result update), but this is consistent with the memtx engine, which doesn't run them in this case, either. It's quite difficult to write a functional test for it without a bunch of ugly error injections so we rely on fuzzing tests. Closes tarantool#10026 NO_DOC=bug fix NO_TEST=fuzzing
locker
added a commit
to locker/tarantool
that referenced
this issue
May 17, 2024
Like UPDATE, UPSERT must not modify primary key parts. Unlike UPDATE, such an invalid UPSERT statement doesn't fail (raise an error) - we just log the error and ignore the statement. The problem is, we don't clear txn_stmt. As a result, if we're currently building a new index, the on_replace trigger installed by the build procedure will try to process this statement, triggering the assertion in the transaction manager that doesn't expect any statements in a secondary index without the corresponding statement in the primary index: ./src/box/vy_tx.c:728: vy_tx_prepare: Assertion `lsm->space_id == current_space_id' failed. Let's fix this by clearing the txn_stmt corresponding to a skipped UPSERT. Note, this also means that on_replace triggers installed by the user won't run on invalid UPSERT (hence test/vinyl/on_replace.result update), but this is consistent with the memtx engine, which doesn't run them in this case, either. It's quite difficult to write a functional test for it without a bunch of ugly error injections so we rely on fuzzing tests. Closes tarantool#10026 NO_DOC=bug fix NO_TEST=fuzzing
locker
added a commit
to locker/tarantool
that referenced
this issue
May 18, 2024
Like UPDATE, UPSERT must not modify primary key parts. Unlike UPDATE, such an invalid UPSERT statement doesn't fail (raise an error) - we just log the error and ignore the statement. The problem is, we don't clear txn_stmt. As a result, if we're currently building a new index, the on_replace trigger installed by the build procedure will try to process this statement, triggering the assertion in the transaction manager that doesn't expect any statements in a secondary index without the corresponding statement in the primary index: ./src/box/vy_tx.c:728: vy_tx_prepare: Assertion `lsm->space_id == current_space_id' failed. Let's fix this by clearing the txn_stmt corresponding to a skipped UPSERT. Note, this also means that on_replace triggers installed by the user won't run on invalid UPSERT (hence test/vinyl/on_replace.result update), but this is consistent with the memtx engine, which doesn't run them in this case, either. Closes tarantool#10026 NO_DOC=bug fix
locker
added
2.11
Target is 2.11 and all newer release/master branches
3.1
Target is 3.1 and all newer release/master branches
labels
May 20, 2024
locker
added a commit
that referenced
this issue
May 20, 2024
Like UPDATE, UPSERT must not modify primary key parts. Unlike UPDATE, such an invalid UPSERT statement doesn't fail (raise an error) - we just log the error and ignore the statement. The problem is, we don't clear txn_stmt. As a result, if we're currently building a new index, the on_replace trigger installed by the build procedure will try to process this statement, triggering the assertion in the transaction manager that doesn't expect any statements in a secondary index without the corresponding statement in the primary index: ./src/box/vy_tx.c:728: vy_tx_prepare: Assertion `lsm->space_id == current_space_id' failed. Let's fix this by clearing the txn_stmt corresponding to a skipped UPSERT. Note, this also means that on_replace triggers installed by the user won't run on invalid UPSERT (hence test/vinyl/on_replace.result update), but this is consistent with the memtx engine, which doesn't run them in this case, either. Closes #10026 NO_DOC=bug fix
locker
added a commit
that referenced
this issue
May 20, 2024
Like UPDATE, UPSERT must not modify primary key parts. Unlike UPDATE, such an invalid UPSERT statement doesn't fail (raise an error) - we just log the error and ignore the statement. The problem is, we don't clear txn_stmt. As a result, if we're currently building a new index, the on_replace trigger installed by the build procedure will try to process this statement, triggering the assertion in the transaction manager that doesn't expect any statements in a secondary index without the corresponding statement in the primary index: ./src/box/vy_tx.c:728: vy_tx_prepare: Assertion `lsm->space_id == current_space_id' failed. Let's fix this by clearing the txn_stmt corresponding to a skipped UPSERT. Note, this also means that on_replace triggers installed by the user won't run on invalid UPSERT (hence test/vinyl/on_replace.result update), but this is consistent with the memtx engine, which doesn't run them in this case, either. Closes #10026 NO_DOC=bug fix (cherry picked from commit 5ac0d26)
locker
added a commit
that referenced
this issue
May 20, 2024
Like UPDATE, UPSERT must not modify primary key parts. Unlike UPDATE, such an invalid UPSERT statement doesn't fail (raise an error) - we just log the error and ignore the statement. The problem is, we don't clear txn_stmt. As a result, if we're currently building a new index, the on_replace trigger installed by the build procedure will try to process this statement, triggering the assertion in the transaction manager that doesn't expect any statements in a secondary index without the corresponding statement in the primary index: ./src/box/vy_tx.c:728: vy_tx_prepare: Assertion `lsm->space_id == current_space_id' failed. Let's fix this by clearing the txn_stmt corresponding to a skipped UPSERT. Note, this also means that on_replace triggers installed by the user won't run on invalid UPSERT (hence test/vinyl/on_replace.result update), but this is consistent with the memtx engine, which doesn't run them in this case, either. Closes #10026 NO_DOC=bug fix (cherry picked from commit 5ac0d26)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug description
A clear and concise description of what the bug is.
Tarantool 3.2.0-entrypoint-33-g39af9fbea6
Target: Linux-x86_64-Debug
Build options: cmake . -DCMAKE_INSTALL_PREFIX=/usr/local -DENABLE_BACKTRACE=TRUE
Compiler: GNU-11.4.0
C_FLAGS: -fexceptions -funwind-tables -fasynchronous-unwind-tables -fno-common -msse2 -Wformat -Wformat-security -Werror=format-security -fstack-protector-strong -fPIC -fmacro-prefix-map=/home/sergeyb/sources/MRG/tarantool=. -std=c11 -Wall -Wextra -Wno-gnu-alignof-expression -fno-gnu89-inline -Wno-cast-function-type -Werror -g -ggdb -O0
CXX_FLAGS: -fexceptions -funwind-tables -fasynchronous-unwind-tables -fno-common -msse2 -Wformat -Wformat-security -Werror=format-security -fstack-protector-strong -fPIC -fmacro-prefix-map=/home/sergeyb/sources/MRG/tarantool=. -std=c++11 -Wall -Wextra -Wno-invalid-offsetof -Wno-gnu-alignof-expression -Wno-cast-function-type -Werror -g -ggdb -O0
Steps to reproduce
Build Tarantool with enabled debug option:
vinyl.lua
How to run:
$ ./build/src/tarantool vinyl.lua
Actual behavior
relevant source code:
tarantool/src/box/vy_tx.c
Line 728 in 39af9fb
And comment above assertion says that "loop below must not yield after recovery".
Expected behavior
no assertions is triggered
The text was updated successfully, but these errors were encountered: