Segementation fault in rollback #6140
Comments
|
It's strange. I cannot get seg fault, but I see strange 'transaction rolled back during snapshot recovery'. |
|
alyapunov
added a commit
that referenced
this issue
Jun 16, 2021
With MVCC a case may happen: TX1 does something with some space and yields. TX2 deletes the space and commits. TX1 rolls back. The problem was that TX1 does something with already deleted space. This commit fixes that. Closes: #6140
|
Actually it's not always a crash. A deleted space was used, that could lead to any result. |
alyapunov
added a commit
that referenced
this issue
Jun 16, 2021
With MVCC a case may happen: TX1 does something with some space and yields. TX2 deletes the space and commits. TX1 rolls back. The problem was that TX1 does something with already deleted space. This commit fixes that. Closes: #6140
alyapunov
added a commit
that referenced
this issue
Jul 2, 2021
With MVCC a case may happen: TX1 does something with some space and yields. TX2 deletes the space and commits. TX1 rolls back. The problem was that TX1 does something with already deleted space. This commit fixes that. Part of #6140
|
A few more buggy examples connected with rollback and schema changes: |
Korablev77
pushed a commit
that referenced
this issue
Jul 5, 2021
With MVCC a case may happen: TX1 does something with some space and yields. TX2 deletes the space and commits. TX1 rolls back. The problem was that TX1 does something with already deleted space. This commit fixes that. Part of #6140
Korablev77
pushed a commit
that referenced
this issue
Jul 5, 2021
With MVCC a case may happen: TX1 does something with some space and yields. TX2 deletes the space and commits. TX1 rolls back. The problem was that TX1 does something with already deleted space. This commit fixes that. Part of #6140
|
Hm it's strange that PR closed this issue even despite the fact that commit contains only "Part of" label... |
Korablev77
added a commit
that referenced
this issue
Jul 16, 2021
To avoid sharing (ergo phantom reads) for different transaction in MVCC mode, let's do following things. Firstly, after modification of any shared objects (like space/user/function caches) disallow transaction to yield to prevent other transactions see that changes. Yield is permitted til the transaction is committed. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. Closes #5998 Closes #6140 Workaround for #6138
Korablev77
added a commit
that referenced
this issue
Jul 19, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, after modification of any shared objects (like space/user/function caches) disallow transaction to yield in order to prevent other transactions see that changes. Yield is permitted til the transaction is committed. In case yield occurs, transaction is aborted. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
Korablev77
added a commit
that referenced
this issue
Jul 27, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, after modification of any shared objects (like space/user/function caches) disallow transaction to yield in order to prevent other transactions see that changes. Yield is permitted til the transaction is committed. In case yield occurs, transaction is aborted. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
Closed
Korablev77
added a commit
that referenced
this issue
Jul 29, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, after modification of any shared objects (like space/user/function caches) disallow transaction to yield in order to prevent other transactions see that changes. Yield is permitted til the transaction is committed. In case yield occurs, transaction is aborted. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
alyapunov
pushed a commit
that referenced
this issue
Aug 2, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, after modification of any shared objects (like space/user/function caches) disallow transaction to yield in order to prevent other transactions see that changes. Yield is permitted til the transaction is committed. In case yield occurs, transaction is aborted. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
Korablev77
added a commit
that referenced
this issue
Aug 2, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, after modification of any shared objects (like space/user/function caches) disallow transaction to yield in order to prevent other transactions see that changes. Yield is permitted til the transaction is committed. In case yield occurs, transaction is aborted. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
Korablev77
added a commit
that referenced
this issue
Aug 4, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
alyapunov
pushed a commit
that referenced
this issue
Aug 10, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
alyapunov
pushed a commit
that referenced
this issue
Aug 12, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
alyapunov
pushed a commit
that referenced
this issue
Aug 13, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
alyapunov
pushed a commit
that referenced
this issue
Aug 13, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
EvgenyMekhanik
pushed a commit
that referenced
this issue
Aug 13, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
alyapunov
pushed a commit
that referenced
this issue
Aug 13, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
Korablev77
added a commit
that referenced
this issue
Aug 14, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
Korablev77
added a commit
that referenced
this issue
Aug 16, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138
Korablev77
added a commit
that referenced
this issue
Aug 16, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138 (cherry picked from commit 8f4be32)
Korablev77
added a commit
that referenced
this issue
Aug 16, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138 (cherry picked from commit 8f4be32)
Korablev77
added a commit
that referenced
this issue
Aug 18, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138 (cherry picked from commit 8f4be32)
Korablev77
added a commit
that referenced
this issue
Aug 18, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138 (cherry picked from commit 8f4be32)
Korablev77
added a commit
that referenced
this issue
Aug 18, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138 (cherry picked from commit 8f4be32)
Korablev77
added a commit
that referenced
this issue
Aug 18, 2021
To avoid sharing (ergo phantom reads) metadata object for different transactions in MVCC mode, let's do following things. Firstly, let's set on replace trigger on all system spaces (content's change in system space is considered to be DDL operation) which disables yields until transaction is committed. The only exceptions are index build and space format check: during these operations yields are allowed since they may take a while (so without yields they block execution). Actually it is not a problem 'cause these two operations must be first-in-transaction: as a result transaction can't contain two yielding statements. So after any cache modification no yields take place for sure. Secondly, on committing transaction that provides DDL changes let's abort all other transaction since they may refer to obsolete schema objects. The last restriction may seem too strict, but it is OK as primitive workaround until transactional DDL is introduced. In fact we should only abort transactions that have read dirty (i.e. modified) objects. Closes #5998 Closes #6140 Workaround for #6138 (cherry picked from commit 8f4be32)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reproducer:
os.execute("rm -rf *.snap *.xlog")
box.cfg {
memtx_use_mvcc_engine = true
}
s = box.schema.space.create('test', { engine = 'memtx' })
_ = s:create_index('primary')
txn_proxy = require('txn_proxy')
tx = txn_proxy:new()
tx:begin()
tx('s:replace{2}')
tx('s:select{}')
s:drop()
tx:rollback()
The text was updated successfully, but these errors were encountered: