Migrations are flaky

[miketheman]

Recent migration efforts have shown that some of the operations requested fail within the time allotted, leading to deploy-time errors. One recent example:

OperationalError: (psycopg.errors.QueryCanceled) canceling statement due to statement timeout
[SQL: ALTER TABLE public."projects" 
                ALTER COLUMN lifecycle_status TYPE public.lifecyclestatus 
                USING lifecycle_status::text::public.lifecyclestatus
                ]

Other migrations with tweaks/twiddles:

• Try Mike's Magic Migration Method #16722
• chore: add composite index for journals #17404
• Make migration version 24aa37164e72 apply immediately #17411
• chore: add some time for migration #17426
• fixup migration: add to enum directly rather than using sync_enum #17427

One Idea, not a great one: #16235

These are often related to some of our more "popular" tables, like projects/releases/files - and we should be able to ship migrations with a little more confidence than we do right now.

[miketheman]

Specifically for enums, we use https://pypi.org/project/alembic-postgresql-enum/ - so it's possible that sync_enum_values() is trying to do too much?

[miketheman]

One idea is https://pgroll.com/ but would require a pretty large restructure of our db/org/migrations, and doesn't support changing enum types yet.