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
ddl: transactional DDL does not care about savepoints #4364
Comments
I thought, that I will fix that, but looks like Vova now is assigned. Nonetheless here are my thoughts on what I had planned to do. Perhaps, it will be useful. The problem is that we can't set on_rollback triggers on individual statements. But we don't need to, strictly speaking. There are only 2 ways, as I know, how a statement can be rolled back:
All cases like rollback on yield, rollback on conflict, voluntary rollback, rollback on an error from WAL, are covered by the case one. |
When reverting to a savepoint inside a DDL transaction, apart from undoing changes done by the DDL statements to the system spaces, we also have to - Run rollback triggers installed after the savepoint was set, because otherwise changes done to the schema by DDL won't be undone. - Remove commit triggers installed after the savepoint, because they are not relevant anymore, apparently. To achieve that, let's remember not only the last transaction statement at the time when a savepoint is created, but also the state of commit and rollback triggers. Since in contrast to txn statements, commit and rollback triggers can actually be deleted from the list, we create dummy triggers per each savepoint and use them as markers in the trigger lists. We don't however create dummy triggers if no commit/rollback triggers is installed, because in that case we would simply need to clear the trigger lists. While we are at it, let's also make sure that a rollback trigger doesn't an already freed tuple. To do that, we release statement tuples after running rollback triggers, not before as we used to. Closes #4364 Closes #4365
When reverting to a savepoint inside a DDL transaction, apart from undoing changes done by the DDL statements to the system spaces, we also have to - Run rollback triggers installed after the savepoint was set, because otherwise changes done to the schema by DDL won't be undone. - Remove commit triggers installed after the savepoint, because they are not relevant anymore, apparently. To achieve that, let's remember not only the last transaction statement at the time when a savepoint is created, but also the state of commit and rollback triggers. Since in contrast to txn statements, commit and rollback triggers can actually be deleted from the list, we create dummy triggers per each savepoint and use them as markers in the trigger lists. We don't however create dummy triggers if no commit/rollback triggers is installed, because in that case we would simply need to clear the trigger lists. While we are at it, let's also make sure that a rollback trigger doesn't access an already freed tuple. To do that, we release statement tuples after running rollback triggers, not before as we used to. Closes #4364 Closes #4365
When reverting to a savepoint inside a DDL transaction, apart from undoing changes done by the DDL statements to the system spaces, we also have to - Run rollback triggers installed after the savepoint was set, because otherwise changes done to the schema by DDL won't be undone. - Remove commit triggers installed after the savepoint, because they are not relevant anymore, apparently. To achieve that, let's remember not only the last transaction statement at the time when a savepoint is created, but also the state of commit and rollback triggers. Since in contrast to txn statements, commit and rollback triggers can actually be deleted from the list, we create dummy triggers per each savepoint and use them as markers in the trigger lists. We don't however create dummy triggers if no commit/rollback triggers is installed, because in that case we would simply need to clear the trigger lists. While we are at it, let's also make sure that a rollback trigger doesn't access an already freed tuple. To do that, we release statement tuples after running rollback triggers, not before as we used to. Closes #4364 Closes #4365
When reverting to a savepoint inside a DDL transaction, apart from undoing changes done by the DDL statements to the system spaces, we also have to - Run rollback triggers installed after the savepoint was set, because otherwise changes done to the schema by DDL won't be undone. - Remove commit triggers installed after the savepoint, because they are not relevant anymore, apparently. To achieve that, let's remember not only the last transaction statement at the time when a savepoint is created, but also the state of commit and rollback triggers. Since in contrast to txn statements, commit and rollback triggers can actually be deleted from the list, we create dummy triggers per each savepoint and use them as markers in the trigger lists. We don't however create dummy triggers if no commit/rollback triggers is installed, because in that case we would simply need to clear the trigger lists. While we are at it, let's also make sure that a rollback trigger doesn't access an already freed tuple. To do that, we release statement tuples after running rollback triggers, not before as we used to. Closes #4364 Closes #4365
When reverting to a savepoint inside a DDL transaction, apart from undoing changes done by the DDL statements to the system spaces, we also have to - Run rollback triggers installed after the savepoint was set, because otherwise changes done to the schema by DDL won't be undone. - Remove commit triggers installed after the savepoint, because they are not relevant anymore, apparently. To achieve that, let's remember not only the last transaction statement at the time when a savepoint is created, but also the state of commit and rollback triggers. Since in contrast to txn statements, commit and rollback triggers can actually be deleted from the list, we create dummy triggers per each savepoint and use them as markers in the trigger lists. We don't however create dummy triggers if no commit/rollback triggers is installed, because in that case we would simply need to clear the trigger lists. While we are at it, let's also make sure that a rollback trigger doesn't access an already freed tuple. To do that, we release statement tuples after running rollback triggers, not before as we used to. Closes #4364 Closes #4365
When reverting to a savepoint inside a DDL transaction, apart from undoing changes done by the DDL statements to the system spaces, we also have to - Run rollback triggers installed after the savepoint was set, because otherwise changes done to the schema by DDL won't be undone. - Remove commit triggers installed after the savepoint, because they are not relevant anymore, apparently. To achieve that, let's remember not only the last transaction statement at the time when a savepoint is created, but also the state of commit and rollback triggers. Since in contrast to txn statements, commit and rollback triggers can actually be deleted from the list, we create dummy triggers per each savepoint and use them as markers in the trigger lists. We don't however create dummy triggers if no commit/rollback triggers is installed, because in that case we would simply need to clear the trigger lists. While we are at it, let's also make sure that a rollback trigger doesn't access an already freed tuple. To do that, we release statement tuples after running rollback triggers, not before as we used to. Closes #4364 Closes #4365
When reverting to a savepoint inside a DDL transaction, apart from undoing changes done by the DDL statements to the system spaces, we also have to - Run rollback triggers installed after the savepoint was set, because otherwise changes done to the schema by DDL won't be undone. - Remove commit triggers installed after the savepoint, because they are not relevant anymore, apparently. To achieve that, let's remember not only the last transaction statement at the time when a savepoint is created, but also the state of commit and rollback triggers. Since in contrast to txn statements, commit and rollback triggers can actually be deleted from the list, we create dummy triggers per each savepoint and use them as markers in the trigger lists. We don't however create dummy triggers if no commit/rollback triggers is installed, because in that case we would simply need to clear the trigger lists. While we are at it, let's also make sure that a rollback trigger doesn't access an already freed tuple. To do that, we release statement tuples after running rollback triggers, not before as we used to. Closes #4364 Closes #4365
Expected output, is that check4 is false, other checks are true. But reality is disappointing:
The text was updated successfully, but these errors were encountered: