Upgrades fail after rollback 1 minor version from master
Summary
Migrations fail during upgrade to latest master after having done a prior rollback using a backup
Steps to reproduce
- Install GitLab version prior to current master (and prior to 14.3.0 release) For example, 14.2.4
- Take backup to use for rollback later
- Upgrade to master
- Rollback in-place to previous version. (Install the previous version over the current version, restore the backup, restart)
- Attempt to upgrade to master again
What is the current bug behavior?
Migrations fail:
StandardError: An error has occurred, this and all later migrations canceled:
PG::DuplicateFunction: ERROR: function "insert_into_loose_foreign_keys_deleted_records" already exists with same argument types
/opt/gitlab/embedded/service/gitlab-rails/db/migrate/20210826145509_add_function_for_inserting_deleted_records.rb:8:in `up'
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database.rb:260:in `block in transaction'
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database.rb:259:in `transaction'
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migrations/lock_retry_mixin.rb:31:in `ddl_transaction'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:61:in `block (3 levels) in <top (required)>'
/opt/gitlab/embedded/bin/bundle:23:in `load'
/opt/gitlab/embedded/bin/bundle:23:in `<main>'
== 20210826145509 AddFunctionForInsertingDeletedRecords: migrating ============
-- execute("CREATE FUNCTION insert_into_loose_foreign_keys_deleted_records()\nRETURNS TRIGGER AS\n$$\nBEGIN\n INSERT INTO loose_foreign_keys_deleted_records\n (deleted_table_name, deleted_table_primary_key_value)\n SELECT TG_TABLE_NAME, old_table.id FROM old_table\n ON CONFLICT DO NOTHING;\n\n RETURN NULL;\nEND\n$$ LANGUAGE PLPGSQL\n")
STDERR:
---- End output of "bash" "/tmp/chef-script20210920-45217-4l5j4s" ----
Ran "bash" "/tmp/chef-script20210920-45217-4l5j4s" returned 1
What is the expected correct behavior?
No failures during migrations
Possible fixes
Add an OR REPLACE
to the migrations causing the error is one option described in !70152 (comment 682298004)
Edited by DJ Mountney