Remove temporary bigint objects for deployment_merge_requests

What does this MR do and why?

This MR is Phase 2 of the bigint conversion of the deployment_merge_requests table. Three post-deployment migrations remove six temporary objects that the column swap left behind. The swap shipped in !255297 (merged) and reached production on 15 September 2026. The canonical columns are bigint. The _convert_to_bigint shadow columns are integer and hold the retired data.

Timestamp	Class	Column	Foreign key removed	Index removed
20260918100005	RemoveTmpBigintFkForDeploymentMergeRequestsToDeployments	deployment_id	fk_rails_dcbce9f4df_tmp to deployments	tmp_idx_deployment_merge_requests_on_deployment_id
20260918100010	RemoveTmpBigintFkForDeploymentMergeRequestsToMergeRequests	merge_request_id	fk_rails_86a6d8bf12_tmp to merge_requests	bigint_idx_bc7ca4c7f2ca0c624100
20260918100012	RemoveTmpBigintFkForDeploymentMergeRequestsToEnvironments	environment_id	fk_a064ff4453_tmp to environments	bigint_idx_58bf293f31365919110b

Migration design

Each migration owns one column, so a migration that cannot take its lock does not block the other two. The up method removes the foreign key, then the index, because a live foreign key with no supporting index makes deletes from the parent table time out. The down method restores both in reverse order and recreates the foreign key as NOT VALID, matching migrations 20260901095603, 20260901095604, and 20260901095605. The file doc/development/database/avoiding_downtime_in_migrations.md requires this order.

The deployment_id index has an unusual history. The swap consumed the prepared bigint index when it became deployment_merge_requests_pkey, which left the temporary foreign key with no support. The merge request !256063 (merged) added migration 20260913042210 to restore it and stated that the index goes when the foreign key goes. This MR removes the foreign key, so it removes the index. Creating the index took 601.8 seconds on the main database clone. Leaving it costs about 6.31 GiB.

The index bigint_idx_58bf293f31365919110b spans two shadow columns, environment_id_convert_to_bigint and merge_request_id_convert_to_bigint, so the down method of 20260918100012 needs both columns. This holds, because the release N+2 cleanup removes all three shadow columns in one call.

Each migration calls can_execute_on? from the WraparoundAutovacuum helper. An anti-wraparound autovacuum runs about five hours and would block the post-deployment pipeline, so these migrations skip rather than wait. Rails records a skip as run, so a skip on GitLab.com needs a retry migration.

References

• Work item: #581431 (closed)
• The column swap: !255297 (merged)
• The MR that created these objects: !252939 (merged)
• The MR that restored the deployment_id index: !256063 (merged)
• Follow-up cleanup: #627123

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.