Skip to content
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

sql: cannot perform other schema changes concurrently with alter column type #47137

Open
Tracked by #49329
RichardJCai opened this issue Apr 7, 2020 · 10 comments
Open
Tracked by #49329
Labels
A-schema-changes C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions) X-anchored-telemetry The issue number is anchored by telemetry references.

Comments

@RichardJCai
Copy link
Contributor

RichardJCai commented Apr 7, 2020

Currently, ALTER COLUMN TYPE cannot be performed concurrently with other schema changes.

For example you cannot add a column while an alter column type is occuring, you cannot alter primary key while alter column type is occuring.

Jira issue: CRDB-5036

Epic CRDB-25314

@RichardJCai RichardJCai changed the title sql: cannot perform alter column type requiring re-encoding disk data while other schema changes are in progress sql: cannot perform other schema changes concurrently with alter column type May 26, 2020
@RichardJCai RichardJCai added A-schema-changes C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) labels May 26, 2020
@RichardJCai
Copy link
Contributor Author

#49351 covers this

@rafiss rafiss added the X-anchored-telemetry The issue number is anchored by telemetry references. label Oct 21, 2020
@rafiss
Copy link
Collaborator

rafiss commented Oct 21, 2020

re-opening, since this is referenced here:

47137, "table %s is currently undergoing a schema change", tableDesc.Name)

@ajwerner
Copy link
Contributor

I feel like this isn't really about wanting the operations to occur concurrently, it's about wanting them to be ordered.

@exalate-issue-sync exalate-issue-sync bot added T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions) and removed T-sql-schema-deprecated Use T-sql-foundations instead labels May 10, 2023
@ddelange
Copy link

CockroachDB executes ALTER COLUMN queries asynchronously which is at
odds with Django's assumption that the database is altered before the next
migration operation begins. CockroachDB will give an error like
unimplemented: table <...> is currently undergoing a schema change if a
later operation tries to modify the table before the asynchronous query
finishes. A future version of CockroachDB may fix this.

ref https://github.com/cockroachdb/django-cockroachdb/blob/5.1/README.md cc @timgraham

is there a possibility to await the change / make the query block until the change finishes?

@ajwerner
Copy link
Contributor

I thought the asynchronous part was fixed such that the statement doesn’t now return until the alter is complete. That comment may be stale. Is it something you see on later cockroach versions?

@ddelange
Copy link

we are in research phase, and this looked like a blocker if we want to move to cockroachdb. can this issue be closed and the django-cockroachdb README amended?

@timgraham
Copy link
Contributor

I believe the stable CockroachDB docs still state this restriction:

Note: Most ALTER COLUMN TYPE changes are finalized asynchronously. Schema changes on the table with the altered column may be restricted, and writes to the altered column may be rejected until the schema change is finalized.

@ajwerner
Copy link
Contributor

@rafiss is it true? My recollection is that the the alter job waits on the job it creates and has for years.

@timgraham
Copy link
Contributor

For context, we saw an intermittent failure in Django with CockroachDB 21.1 (#65691). Since then the test has been on the skip list.

@ddelange
Copy link

hi all 👋

did you happen to discuss this internally in the meantime?

this would be a hard blocker to migrate our django project over from vanilla postgres

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-schema-changes C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions) X-anchored-telemetry The issue number is anchored by telemetry references.
Projects
None yet
Development

No branches or pull requests

5 participants