sql/schemachanger: concurrent legacy/declarative schema changes on type descriptors can hang #89831
Assignees
Labels
branch-release-22.2
Used to mark GA and release blockers, technical advisories, and bugs for 22.2
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
Comments
fqazi
added
C-bug
craig bot
pushed a commit
that referenced
this issue
Oct 12, 2022
89846: sql/schemachanger: prevent concurrent declarative/legacy usage for types r=fqazi a=fqazi Fixes: #89831, #87572 Previously, it was possible for the declarative schema changer drop type operations and other legacy schema changer operations for types to overlap. This was problematic because if any legacy type descriptor-related schema change job saw that a type descriptor is labelled as dropped, we would delete the descriptor as a part the legacy schema changer job. This would happen for example if we had a DROP TYPE and ALTER TYPE operations running concurrently, with the former in the declarative schema changer. The declarative schema changer during the commit phase will mark the descriptor as dropped, and delete the descriptor using a job. The alter type legacy schema changer job if started afterwards will drop the type descriptor if it's marked as dropped before the declarative schema change job starts, causing the declarative to hang later on if the descriptor is missing. To address this, this patch will prevent the legacy schema changer jobs from dropping a type descriptor, if a declarative schema changer exists inside it. Release note: None Co-authored-by: Faizan Qazi <[email protected]>
blathers-crl bot
pushed a commit
that referenced
this issue
Oct 12, 2022
Fixes: #89831, #87572 Previously, it was possible for the declarative schema changer drop type operations and other legacy schema changer operations for types to overlap. This was problematic because if any legacy type descriptor-related schema change job saw that a type descriptor is labelled as dropped, we would delete the descriptor as a part the legacy schema changer job. This would happen for example if we had a DROP TYPE and ALTER TYPE operations running concurrently, with the former in the declarative schema changer. The declarative schema changer during the commit phase will mark the descriptor as dropped, and delete the descriptor using a job. The alter type legacy schema changer job if started afterwards will drop the type descriptor if it's marked as dropped before the declarative schema change job starts, causing the declarative to hang later on if the descriptor is missing. To address this, this patch will prevent the legacy schema changer jobs from dropping a type descriptor, if a declarative schema changer exists inside it. Release note: None
blathers-crl bot
pushed a commit
that referenced
this issue
Oct 12, 2022
Fixes: #89831, #87572 Previously, it was possible for the declarative schema changer drop type operations and other legacy schema changer operations for types to overlap. This was problematic because if any legacy type descriptor-related schema change job saw that a type descriptor is labelled as dropped, we would delete the descriptor as a part the legacy schema changer job. This would happen for example if we had a DROP TYPE and ALTER TYPE operations running concurrently, with the former in the declarative schema changer. The declarative schema changer during the commit phase will mark the descriptor as dropped, and delete the descriptor using a job. The alter type legacy schema changer job if started afterwards will drop the type descriptor if it's marked as dropped before the declarative schema change job starts, causing the declarative to hang later on if the descriptor is missing. To address this, this patch will prevent the legacy schema changer jobs from dropping a type descriptor, if a declarative schema changer exists inside it. Release note: None
blathers-crl bot
pushed a commit
that referenced
this issue
Jan 3, 2023
Fixes: #89831, #87572 Previously, it was possible for the declarative schema changer drop type operations and other legacy schema changer operations for types to overlap. This was problematic because if any legacy type descriptor-related schema change job saw that a type descriptor is labelled as dropped, we would delete the descriptor as a part the legacy schema changer job. This would happen for example if we had a DROP TYPE and ALTER TYPE operations running concurrently, with the former in the declarative schema changer. The declarative schema changer during the commit phase will mark the descriptor as dropped, and delete the descriptor using a job. The alter type legacy schema changer job if started afterwards will drop the type descriptor if it's marked as dropped before the declarative schema change job starts, causing the declarative to hang later on if the descriptor is missing. To address this, this patch will prevent the legacy schema changer jobs from dropping a type descriptor, if a declarative schema changer exists inside it. Release note: None
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The legacy schema changer's type schema change jobs and declarative schema changer jobs can
interact with each other, which can lead to a hang scenario. This can happen for example if a DROP TYPE
in the declarative schema changer is executed concurrently with any modification to the type descriptor,
for example, a REASSIGN OWNED BY which would impact a type. The type schema changer job will
clean up any type descriptors marked as dropped, which the DROP command will do during the commit,
and create a job to clean up the actual descriptor during POST COMMIT. However, when the declarative job
goes to look for this descriptor it will be removed.
Jira issue: CRDB-20466
The text was updated successfully, but these errors were encountered: