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 skippedA 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
- Related to #551602
- Swaps the columns this cleans up after: !248015 (merged)
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.