Fix truncate for detached partitions
What does this MR do and why?
Fix truncate for detached partitions
For some yet-to-be determined reason the FK constraints for these
"detached" partition tables are now stored in the
gitlab_partitions_dynamic schema. They used to be stored in the
public schema.
This affected the truncate_legacy_tables rake task as tables such as
alert_management_alerts are not truncated correctly.
See
gitlab-development-kit#1907 (closed).
As we have a mixture where some of these FKs are in
gitlab_partitions_dynamic, and some are in public, we need to query
both to get the foreign keys correctly.
Update specs with this scenario.
Screenshots or screen recordings
FK for incident_management_pending_alert_escalations and partitions in my GDK.
gitlabhq_development=# SELECT * FROM information_schema.table_constraints where constraint_name = 'fk_rails_f3d17bc8af';
constraint_catalog | constraint_schema | constraint_name | table_catalog | table_schema | table_name | constraint_type | is_deferrable | initially_deferred | enforced
----------------------+---------------------------+---------------------+----------------------+---------------------------+------------------------------------------------------+-----------------+---------------+--------------------+----------
gitlabhq_development | public | fk_rails_f3d17bc8af | gitlabhq_development | gitlab_partitions_dynamic | incident_management_pending_alert_escalations_202312 | FOREIGN KEY | NO | NO | YES
gitlabhq_development | public | fk_rails_f3d17bc8af | gitlabhq_development | public | incident_management_pending_alert_escalations | FOREIGN KEY | NO | NO | YES
gitlabhq_development | public | fk_rails_f3d17bc8af | gitlabhq_development | gitlab_partitions_dynamic | incident_management_pending_alert_escalations_202401 | FOREIGN KEY | NO | NO | YES
gitlabhq_development | public | fk_rails_f3d17bc8af | gitlabhq_development | gitlab_partitions_dynamic | incident_management_pending_alert_escalations_202402 | FOREIGN KEY | NO | NO | YES
gitlabhq_development | gitlab_partitions_dynamic | fk_rails_f3d17bc8af | gitlabhq_development | gitlab_partitions_dynamic | incident_management_pending_alert_escalations_202306 | FOREIGN KEY | NO | NO | YES
gitlabhq_development | gitlab_partitions_dynamic | fk_rails_f3d17bc8af | gitlabhq_development | gitlab_partitions_dynamic | incident_management_pending_alert_escalations_202307 | FOREIGN KEY | NO | NO | YES
gitlabhq_development | gitlab_partitions_dynamic | fk_rails_f3d17bc8af | gitlabhq_development | gitlab_partitions_dynamic | incident_management_pending_alert_escalations_202308 | FOREIGN KEY | NO | NO | YES
gitlabhq_development | gitlab_partitions_dynamic | fk_rails_f3d17bc8af | gitlabhq_development | gitlab_partitions_dynamic | incident_management_pending_alert_escalations_202309 | FOREIGN KEY | NO | NO | YES
gitlabhq_development | gitlab_partitions_dynamic | fk_rails_f3d17bc8af | gitlabhq_development | gitlab_partitions_dynamic | incident_management_pending_alert_escalations_202310 | FOREIGN KEY | NO | NO | YES
gitlabhq_development | gitlab_partitions_dynamic | fk_rails_f3d17bc8af | gitlabhq_development | gitlab_partitions_dynamic | incident_management_pending_alert_escalations_202311 | FOREIGN KEY | NO | NO | YES
gitlabhq_development | gitlab_partitions_dynamic | fk_rails_f3d17bc8af | gitlabhq_development | gitlab_partitions_dynamic | incident_management_pending_alert_escalations_202305 | FOREIGN KEY | NO | NO | YES
(11 rows)
How to set up and validate locally
bundle exec rake gitlab:db:truncate_legacy_tables:ci
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.