Skip to content

Remove a temporary index on ci_builds meant only for earlier migration

Gregory Stark requested to merge remove-temporary-ci-index into master

Migration 20170919211300_remove_temporary_ci_builds_index.rb created a temporary partial index and tried to drop it at the end of the migration. In some circumstances apparently it failed to drop the index and it ended up in our schema.rb.

This accidentally failed to fail due to a bug in the regular expression for partial indexes which caused the index creation in schema.rb to be ignored. Now that that's fixed we could be resurrecting this zombie index from the past in some but not all databases.

Add a migration to drop this index if it's present to reconcile this discrepancy.

Are there points in the code the reviewer needs to double check?

This should be picked for stable so that we don't release any version with this erroneous index in it.

== 20170919211300 RemoveTemporaryCiBuildsIndex: migrating =====================
-- index_exists?(:ci_builds, :id, {:name=>"index_for_ci_builds_retried_migration"})
   -> 0.0080s
-- transaction_open?()
   -> 0.0000s
-- select_one("SELECT current_setting('server_version_num') AS v")
   -> 0.0015s
-- execute("SET statement_timeout TO 0")
   -> 0.0004s
-- remove_index(:ci_builds, {:name=>"index_for_ci_builds_retried_migration", :algorithm=>:concurrently, :column=>:id})
   -> 0.0757s
== 20170919211300 RemoveTemporaryCiBuildsIndex: migrated (0.0860s) ============

Database Checklist

When adding migrations:

  • Updated db/schema.rb
  • Added a down method so the migration can be reverted
  • Added the output of the migration(s) to the MR body
  • Added the execution time of the migration(s) to the MR body
  • Added tests for the migration in spec/migrations if necessary (e.g. when migrating data)
  • Made sure the migration won't interfere with a running GitLab cluster, for example by disabling transactions for long running migrations

When adding or modifying queries to improve performance:

  • Included the raw SQL queries of the relevant queries
  • Included the output of EXPLAIN ANALYZE and execution timings of the relevant queries
  • Added tests for the relevant changes

When adding indexes:

  • Described the need for these indexes in the MR body
  • Made sure existing indexes can not be reused instead

When adding foreign keys to existing tables:

  • Included a migration to remove orphaned rows in the source table
  • Removed any instances of dependent: ... that may no longer be necessary

When adding tables:

  • Ordered columns based on their type sizes in descending order
  • Added foreign keys if necessary
  • Added indexes if necessary

When removing columns, tables, indexes or other structures:

  • Removed these in a post-deployment migration
  • Made sure the application no longer uses (or ignores) these structures

General Checklist

Edited by Gregory Stark

Merge request reports