Clean up deployment_clusters bigint conversion

Marius Bobinrequested to merge
627120-remove-deployment-clusters-bigint-artifacts into master

What does this MR do and why?

Completes the release N+2 database cleanup for the deployment_clusters bigint conversion.

Production already uses bigint for the canonical deployment_id and cluster_id columns. This MR removes what the conversion left behind:

  • the integer shadow columns deployment_id_convert_to_bigint and cluster_id_convert_to_bigint
  • the bigint synchronization trigger trigger_c08229f1c143 and its function

The project sharding-key trigger trigger_ad05b7ebe49b is unrelated to the conversion and is retained.

db/integer_ids_not_yet_initialized_to_bigint.yml is updated by cleanup_conversion_of_integer_to_bigint, not by hand.

db/structure.sql is unchanged. New installations already have the final schema, as described in migrating integer primary keys to bigint.

Why down is a no-op

Restoring the shadow columns and the sync trigger reactivates the historical conversion chain. Earlier steps in that chain have empty down methods, so a rollback past this point fails on objects they never restore. The same problem was hit on the deployments cleanup and resolved the same way.

The migration is guarded by WraparoundAutovacuum#can_execute_on? and skips (recorded as applied) if a wraparound-prevention vacuum is active on deployment_clusters. A skip on GitLab.com requires a follow-up retry migration.

Conversion history

The DeploymentCluster ignored-column rules stay in place. They are removed in release N+3, tracked by #627121 (closed).

Migration output

Up 
== 20260901090003 CleanUpBigintConversionForDeploymentClusters: migrating =====
-- table_exists?("deployment_clusters")
-- columns("deployment_clusters")
-- transaction_open?(nil)
-- primary_key("deployment_clusters")
-- remove_column("deployment_clusters", "deployment_id_convert_to_bigint", {:if_exists=>true})
-- remove_column("deployment_clusters", "cluster_id_convert_to_bigint", {:if_exists=>true})
-- columns("deployment_clusters")
== 20260901090003 CleanUpBigintConversionForDeploymentClusters: migrated (0.0685s)

How to set up and validate locally

  1. Run ./scripts/regenerate-schema.

  2. Confirm db/structure.sql has no changes.

  3. Confirm the deployment_clusters entry is gone from db/integer_ids_not_yet_initialized_to_bigint.yml.

  4. Inspect the table and confirm the shadow columns and trigger_c08229f1c143 are absent, while trigger_ad05b7ebe49b remains:

    gdk psql -d gitlabhq_test -c '\d deployment_clusters'

Local result after the migration:

        Column        |          Type          | Collation | Nullable | Default
----------------------+------------------------+-----------+----------+---------
 deployment_id        | bigint                 |           | not null |
 cluster_id           | bigint                 |           | not null |
 kubernetes_namespace | character varying(255) |           |          |
 project_id           | bigint                 |           |          |
Indexes:
    "deployment_clusters_pkey" PRIMARY KEY, btree (deployment_id)
    "idx_deployment_clusters_on_cluster_id_and_kubernetes_namespace" btree (cluster_id, kubernetes_namespace)
    "index_deployment_clusters_on_cluster_id_and_deployment_id" UNIQUE, btree (cluster_id, deployment_id)
    "index_deployment_clusters_on_project_id" btree (project_id)
Check constraints:
    "check_bb095c4b11" CHECK (project_id IS NOT NULL)
Foreign-key constraints:
    "fk_8338580a3e" FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE
    "fk_rails_6359a164df" FOREIGN KEY (deployment_id) REFERENCES deployments(id) ON DELETE CASCADE
Triggers:
    trigger_ad05b7ebe49b BEFORE INSERT OR UPDATE ON deployment_clusters FOR EACH ROW EXECUTE FUNCTION trigger_ad05b7ebe49b()

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.

Resolves #627120 (closed)

Merge request reports