Remove index by name on ci_pipelines
What does this MR do?
In some older instances, there's a duplicate index on ci_pipelines.project_id
.
This causes upgrades to >12.7 to fail because the migration introduced in !22325 (merged) fails with:
ArgumentError: Multiple indexes found on ci_pipelines columns [:project_id]. Specify an index name from ci_pipelines_project_id_idx, index_ci_pipelines_on_project_id
This MR updates the migration to remove both indexes explicitly by name.
Related to #36042 (closed)
Closes #215790 (closed)
Testing
╰─>$ RAILS_ENV=test bin/rails dbconsole
gitlabhq_test=# create index index_ci_pipelines_on_project_id on ci_pipelines (project_id);
CREATE INDEX
gitlabhq_test=# create index ci_pipelines_project_id_idx on ci_pipelines (project_id);
CREATE INDEX
╰─>$ RAILS_ENV=test bin/rake db:migrate:up VERSION=20191229140154
== 20191229140154 DropIndexCiPipelinesOnProjectId: migrating ==================
-- transaction_open?()
-> 0.0000s
-- indexes(:ci_pipelines)
-> 0.0055s
-- execute("SET statement_timeout TO 0")
-> 0.0004s
-- remove_index(:ci_pipelines, {:algorithm=>:concurrently, :name=>"index_ci_pipelines_on_project_id"})
-> 0.0018s
-- execute("RESET ALL")
-> 0.0004s
-- transaction_open?()
-> 0.0000s
-- indexes(:ci_pipelines)
-> 0.0033s
-- execute("SET statement_timeout TO 0")
-> 0.0004s
-- remove_index(:ci_pipelines, {:algorithm=>:concurrently, :name=>"ci_pipelines_project_id_idx"})
-> 0.0010s
-- execute("RESET ALL")
-> 0.0003s
== 20191229140154 DropIndexCiPipelinesOnProjectId: migrated (0.0134s) =========
╰─>$ RAILS_ENV=test bin/rake db:migrate:down VERSION=20191229140154
== 20191229140154 DropIndexCiPipelinesOnProjectId: reverting ==================
-- transaction_open?()
-> 0.0000s
-- index_exists?(:ci_pipelines, :project_id, {:name=>"index_ci_pipelines_on_project_id", :algorithm=>:concurrently})
-> 0.0063s
-- execute("SET statement_timeout TO 0")
-> 0.0006s
-- add_index(:ci_pipelines, :project_id, {:name=>"index_ci_pipelines_on_project_id", :algorithm=>:concurrently})
-> 0.0112s
-- execute("RESET ALL")
-> 0.0006s
== 20191229140154 DropIndexCiPipelinesOnProjectId: reverted (0.0190s) =========
Merge request reports
Activity
added databasereview pending label
2 Warnings This merge request does not refer to an existing milestone. You’ve made some app changes, but didn’t add any tests.
That’s OK as long as you’re refactoring existing code,
but please consider adding any of the ~”backstage”, ~”documentation”, ~”QA” labels.Reviewer roulette
Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category (e.g. frontend or backend), and by a maintainer in all other categories.
To spread load more evenly across eligible reviewers, Danger has randomly picked a candidate for each review slot. Feel free to override these selections if you think someone else would be better-suited, or the chosen person is unavailable.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines.
Once you've decided who will review this merge request, mention them as you normally would! Danger does not (yet?) automatically notify them for you.
Category Reviewer Maintainer database Patrick Bair ( @pbair
)Toon Claes ( @toon
)Generated by
DangerEdited by 🤖 GitLab Bot 🤖- Resolved by Andreas Brandl
@pbair - mind reviewing this please?
- mostly similar to !19362 (merged)Also, I'm not sure about the process - do we backport back to 12.7 where this got introduced? Otherwise, I can follow-up with a doc update too, maybe around the 12.7 specific upgrade changes
Edited by Catalin Irimie
added databasereviewed label and removed databasereview pending label
@abrandl - mind doing the maintainer review?
(sorry for not going with the roulette suggestion - for Danger)Edited by Catalin Irimieadded databaseapproved label and removed databasereviewed label
Thanks @cat!
In terms of backporting this, I would defer to @nolith if that would be eligible to go back to %12.7.
Thinking this goes in the direction of this, because it prohibits a seemless upgrade in some cases.
Potentially affecting one or more strategic accounts due to a proven inability by the user to upgrade to the current stable version.
https://docs.gitlab.com/ee/policy/maintenance.html#backporting-to-older-releases
Also see this thread above: !31043 (comment 337074808)
Edited by Andreas BrandlThanks @nolith @abrandl - I ended up not creating one after re-reading through the policy and the backport request template - it's limited in impact (very old instances, only seen 3 cases so far, 1 customer) and no data loss potential, but it's likely a "good" candidate for ~"Pick into 12.10" - as folks upgrading directly to 13.0 would still need to go through 12.10 and they may run into this.
I'm not sure what's the "process" for that - so, sorry for the double ping, do I actually need to create a backport request for that too - or is it just adding the ~"Pick into 12.10" label since it's the current stable release?
Thank you @cat
You can add ~"Pick into 12.10" and it will handled by the next patch release.
enabled an automatic merge when the pipeline for 29a5a46e succeeds
mentioned in commit 57c38db8
added workflowcanary label
added workflowproduction label and removed workflowcanary label
picked the changes into the branch
12-10-stable-ee-patch-6
with commit c660b000Automatically picked into !32294 (merged), will merge into
12-10-stable-ee
ready for12.10.6-ee
.mentioned in commit c660b000
mentioned in merge request !32294 (merged)
mentioned in issue gitlab-com/support/support-team-meta#2351 (closed)
added devopsdata stores label and removed devopssystems label
added groupdatabase frameworks label and removed groupdatabase [DEPRECATED] label
added pipeline:mr-approved label