workload/schemachange: ensure unique column numbers upon table creation#58038
Merged
craig[bot] merged 1 commit intocockroachdb:masterfrom Dec 17, 2020
Merged
Conversation
Member
|
This change is |
Previously, the following behaviour would result in a seg fault: First a table (eg. table1) gets created with col1_0, col1_1, col1_2 where thec column numbers (0,1,2) refer to their index in the table. After table creation, the workload tries to intentionally cause an error by altering the type of a column that does not exist. From the perspective of the workload, the sequence numbers (0,1,2) have not been used, so it may use one of the column names above (eg. col1_0) while assuming the column name is unique compared to any column names in the db. This assumption leads to a seg fault because it is not correct. Specifically, a column variable representing a column that does not exist will have a nil type. If the workload checks the database for this column, sees that it exists, then tries to dereference the type, a seg fault will occur. This change ensures that table creation uses the workload's atomically increasing global sequence number while naming columns. This ensures that the assumption above holds true and prevents the seg fault from occurring. Closes: cockroachdb#58017 Release note: None
cbcaa88 to
a122abf
Compare
ajwerner
approved these changes
Dec 17, 2020
Contributor
ajwerner
left a comment
There was a problem hiding this comment.
Reviewed 2 of 2 files at r1.
Reviewable status:complete! 1 of 0 LGTMs obtained
Contributor
Author
|
bors r=ajwerner |
Contributor
|
Build succeeded: |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
workload/schemachange: ensure unique column numbers upon table creation
Previously, the following behaviour would result in a seg fault:
First a table (eg. table1) gets created with col1_0, col1_1, col1_2
where thec column numbers (0,1,2) refer to their index in the table.
After table creation, the workload tries to intentionally cause an
error by altering the type of a column that does not exist. From the
perspective of the workload, the sequence numbers (0,1,2) have not
been used, so it may use one of the column names above (eg. col1_0)
while assuming the column name is unique compared to any column names
in the db. This assumption leads to a seg fault because it is not
correct. Specifically, a column variable representing a column that
does not exist will have a nil type. If the workload checks the database
for this column, sees that it exists, then tries to dereference the type,
a seg fault will occur.
This change ensures that table creation uses the workload's atomically
increasing global sequence number while naming columns. This ensures
that the assumption above holds true and prevents the seg fault from
occurring.
Closes: #58017
Release note: None