Remove tmp bigint FK for deployments phase two

Marius Bobinrequested to merge
551602-retry-drop-tmp-fk-deployments-phase-two into master

What does this MR do and why?

Removing fk_b9a3851b82_tmp (deployments.project_id_convert_to_bigint -> projects.id) did not take effect in production when !248030 (merged) ran. That migration has already run and will not run again, so the foreign key needs a migration of its own.

Two changes:

  1. DropTmpBigintIndexesAndFkForDeploymentsPhaseTwo drops the foreign key handling from both up and down, leaving it responsible only for the temporary indexes, which it removed successfully.
  2. A new post-deployment migration removes the foreign key, and restores it on rollback.

The eight temporary indexes are unaffected and stay where they are.

The new migration

Removing the foreign key is idempotent, since remove_foreign_key_if_exists returns early when the constraint is absent. It is therefore a no-op anywhere the earlier migration already succeeded, including self-managed installations.

down recreates the foreign key as NOT VALID, matching how AddBigintFkForDeploymentsPhaseTwo first added it, so a rollback does not pay for a full table validation.

Both directions return early while a wraparound prevention vacuum is running on deployments, so the migration can be retried on a later deployment rather than holding up the post deployment pipeline.

Verification

db/structure.sql is unchanged.

References

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports