Drop tmp bigint indexes and FK for deployments phase two

What does this MR do and why?

After project_id and user_id are swapped with their bigint counterparts, the temporary indexes and foreign key created for the conversion are left over on the old integer columns. They serve no purpose and cost space and write overhead, so this drops them:

  • the eight bigint_idx_* indexes
  • fk_b9a3851b82_tmp (project_id_convert_to_bigint -> projects.id)

This mirrors DropTmpBigintIndexesAndFkForDeploymentsPhaseOne (db/post_migrate/20260319230454).

Stacked on !248015 (merged), which performs the swap. The migration is guarded on the conversion columns holding the integer type, which is only true once the swap has run, so it is a no-op anywhere the swap has not been applied.

Rollback

down recreates the indexes and re-adds the foreign key as NOT VALID, matching how it was first added. Phase one shipped an empty down, but there the swap and the cleanup were a single merge request, so a partial rollback was never reachable. Splitting them makes it reachable, and without a working down the swap could no longer be reverted.

remove_concurrent_index_by_name and remove_foreign_key_if_exists both tolerate missing objects, so up needs no explicit existence check. This matters for index_deployments_on_user_id_and_status_and_created_at, whose bigint twin does not exist on GitLab.com.

Verification

db/structure.sql is unchanged. The migration was executed against the test database and self-skipped as expected:

main: == 20260731085558 DropTmpBigintIndexesAndFkForDeploymentsPhaseTwo: migrating ==
main: -- column_exists?("deployments", "project_id_convert_to_bigint")
main: -- Not all conversion columns found - migration skipped

A schema built from structure.sql has no _convert_to_bigint columns, so a local run cannot exercise the real path. The database-testing-automation job against a production-like clone is the meaningful check.

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.

Edited by Marius Bobin

Merge request reports

Loading
Loading