Swaps merge_request_diff_commits with its partitioned replacement

‼️ The following steps should be completed first ‼️


What does this MR do and why?

Swaps merge_request_diff_commits with the partitioned merge_request_diff_commits_b5377a7a34 table on GitLab.com, via a post-deployment migration. The old table is renamed to merge_request_diff_commits_archived, the partitioned table takes over the live name, and the forward sync triggers (old -> new) are replaced with reverse sync triggers (new -> archived).

The swap itself is GitLab.com only (Gitlab.com_except_jh?): the backfill is complete and finalised there (!243447 (merged)), while self-managed will swap at a required stop in a later release because FF mr_diff_commits_read_new_table needs to be rolled out before the swap.

Because the migration no-ops in dev/test, structure.sql is unchanged and every CI pipeline only exercises the unswapped (rollback) state.

Key decisions & risk mitigation

  • int4 ceiling on the archived table. The reverse insert skips rows with merge_request_diff_id > 2147483647. Without this filter, the first diff ID past the ceiling would raise integer out of range inside the trigger and abort every insert into the live table. Skipped rows are harmless: past that boundary the archived table cannot hold new rows and rollback is impossible regardless. A follow-up PDM will drop the reverse triggers once the swap is confirmed stable (!251603 (merged)).

Database

  • Table swap: SwapMergeRequestDiffCommitsTable swaps the legacy merge_request_diff_commits heap table with its partitioned replacement merge_request_diff_commits_b5377a7a34 via post-deployment migration. The old table is renamed to merge_request_diff_commits_archived as a safety net.
  • Sync triggers: The same migration replaces forward sync triggers (legacy → partitioned) with reverse sync triggers (partitioned → archived) to ensure rollback remains lossless and data written during the swap is preserved.
  • Lock safety: All operations run in a single with_lock_retries transaction with escalating timeouts to mitigate lock contention on this high-traffic table.
  • Partition management: Both table names are registered in postgres_partitioning.rb to keep partition creation working during the window between deploy and migration execution.
  • Idempotency: The swap is guarded by table_exists?(ARCHIVED_TABLE) to safely handle re-runs; triggers and functions use CREATE OR REPLACE for safety.
  • Latest db job result: #note_3579529090

References

Related to #527241

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 Eugenia Grieff

Merge request reports

Loading
Loading