sql: drop check/FK/non-null constraints in the schema changer #39648
Conversation
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
|
This change is |
thoszhang
force-pushed
the
drop-constraint-schema-changer
branch
2 times, most recently
from
1a09e81 to
6fccda7
Compare
thoszhang
changed the title
thoszhang
force-pushed
the
drop-constraint-schema-changer
branch
2 times, most recently
from
a011984 to
9d12837
Compare
thoszhang
force-pushed
the
drop-constraint-schema-changer
branch
2 times, most recently
from
985e38c to
43e77c0
Compare
dt
approved these changes
Aug 15, 2019
thoszhang
force-pushed
the
drop-constraint-schema-changer
branch
2 times, most recently
from
a3e393e to
5fe96d2
Compare
Previously, `DROP CONSTRAINT` for check, foreign key, and non-null constraints would cause those constraints to be immediately removed from the table descriptor in a single transaction, which causes inconsistencies if the constraint was validated and the optimizer was relying on those constraints to hold. In this PR, constraints are now dropped in the schema changer if they were previously validated. The existing code path is preserved for clusters not fully upgraded to 19.2. This PR slightly changes the behavior of `DROP CONSTRAINT` statements within transactions: Since constraints are not removed immediately, they are still enforced for writes within the same transaction, in the same way that constraints are _not_ enforced within the same transaction in which they are added. (The difference is that when adding constraints in a transaction that also contains writes, a validation query is run before any results are returned to the client, and the schema change is rolled back if necessary.) Release note (sql change): When `DROP CONSTRAINT` is executed in a transaction on a validated constraint, it no longer takes effect immediately, and subsequent writes in that constraint will now fail if they violate that constraint. This is to enforce consistency when dropping constraints asynchronously in the schema changer.
thoszhang
force-pushed
the
drop-constraint-schema-changer
branch
from
5fe96d2 to
183acd7
Compare
|
bors r+ |
craig bot
pushed a commit
that referenced
this pull request
Aug 20, 2019
39648: sql: drop check/FK/non-null constraints in the schema changer r=lucy-zhang a=lucy-zhang Previously, `DROP CONSTRAINT` for check, foreign key, and non-null constraints would cause those constraints to be immediately removed from the table descriptor in a single transaction, which causes inconsistencies if the constraint was validated and the optimizer was relying on those constraints to hold. In this PR, constraints are now dropped in the schema changer if they were previously validated. The existing code path is preserved for clusters not fully upgraded to 19.2. This PR slightly changes the behavior of `DROP CONSTRAINT` statements within transactions: Since constraints are not removed immediately, they are still enforced for writes within the same transaction, in the same way that constraints are _not_ enforced within the same transaction in which they are added. (The difference is that when adding constraints in a transaction that also contains writes, a validation query is run before any results are returned to the client, and the schema change is rolled back if necessary.) Release note (sql change): When `DROP CONSTRAINT` is executed in a transaction on a validated constraint, subsequent writes in that constraint will now fail if they violate that constraint. This is to enforce consistency when dropping constraints asynchronously in the schema changer. Co-authored-by: Lucy Zhang <[email protected]>
Build succeeded |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Previously,
DROP CONSTRAINTfor check, foreign key, and non-null constraintswould cause those constraints to be immediately removed from the table
descriptor in a single transaction, which causes inconsistencies if the
constraint was validated and the optimizer was relying on those constraints to
hold. In this PR, constraints are now dropped in the schema changer if they
were previously validated. The existing code path is preserved for clusters not
fully upgraded to 19.2.
This PR slightly changes the behavior of
DROP CONSTRAINTstatements withintransactions: Since constraints are not removed immediately, they are still
enforced for writes within the same transaction, in the same way that
constraints are not enforced within the same transaction in which they are
added. (The difference is that when adding constraints in a transaction that
also contains writes, a validation query is run before any results are returned
to the client, and the schema change is rolled back if necessary.)
Release note (sql change): When
DROP CONSTRAINTis executed in a transactionon a validated constraint, subsequent writes in that constraint will now fail
if they violate that constraint. This is to enforce consistency when dropping
constraints asynchronously in the schema changer.