DB Migration Fails When Running Upgrade 6c7537a6004a -> 3e1b21cd94a4 #6606
Comments
kristw
added
#question
!deprecated-label:bug
|
I am running the docker-compose based on the latest source and got stuck on the same step. Then it is hanging and no reponse. |
|
I'm having the same problem. When I look at the psql running queries I see 3 seemly identical queries: there is a blocking query: ALTER TABLE tables DROP CONSTRAINT user_id I'm working on trying to debug where in the upgrade script that is happening. |
|
I get to the same point. Occasionally, I will get to the next upgrade line, but mostly get stuck here like @travisgu |
|
I'm running with docker compose. I found that if I kill the |
|
I've done that and I get a list of errors, the top of which: and the following when pulling up the superset page: You didn't see these types of errors when you terminated the alter script? |
|
I'm facing same issue. DB upgrade gets stuck at 'ALTER TABLE tables DROP CONSTRAINT user_id'. |
|
So it looks like some the issues are around lingering locks. So either you find the locking processes and kill them, or another option is to schedule downtime, stop all the web servers, and restart the database process prior to running the migration. There are different ways to hack around alembic (the migration toolkit we use). You can tweak the migration code to skip steps and apply them manually with the proper ALTER command. You can also skip migrations by setting the |
|
Ran into this on our test env and was later able to replicate on SELECT blocked_locks.pid AS blocked_pid,
blocked_activity.usename AS blocked_user,
blocking_locks.pid AS blocking_pid,
blocking_activity.usename AS blocking_user,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS current_statement_in_blocking_process
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;and then killing each violating PID ( SELECT pg_terminate_backend(PID);Just make sure you kill the blocking PID, not the blocked PID. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue |
|
Also ran into this. SELECT ab_permission_view.id AS ab_permission_view_id,
ab_permission_view.permission_id AS ab_permission_view_permission_id,
ab_permission_view.view_menu_id AS ab_permission_view_view_menu_id
FROM ab_permission_view
WHERE 13 = ab_permission_view.permission_id AND 25 = ab_permission_view.view_menu_id
LIMIT 1Looking at pg_stat_activity, this query was fired first, sitting in ALTER TABLE ab_view_menu ALTER COLUMN name TYPE VARCHAR(255)is executed, but it locks, as ab_permission_view references ab_view_menu (and select+alter table on the same table block, as per https://www.citusdata.com/blog/2018/02/15/when-postgresql-blocks/) Anyhow, this was reported earlier, see #1260 (comment) |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue |
Make sure these boxes are checked before submitting your issue - thank you!
Superset version
Superset 0.999.0dev
Expected results
DB Upgrade migration completes successfully
Actual results
DB Upgrade migration fails with the following error:
Steps to reproduce
Build superset from source
Run the command
superset db upgradeThe text was updated successfully, but these errors were encountered: