Migratieproblemen door het stoppen van een herstel voordat het voltooid was

Ondersteuning
1 
PG::DependentObjectsStillExist: ERROR:  cannot drop function delete_user_password() because other objects depend on it

Seems to come from here:

2

Het is een postmigratie:


== 20240910090759 MakePasswordColumnsFromUsersReadOnly: migreren =============
-- execute("DROP TRIGGER IF EXISTS users_password_sync_on_delete_password ON users;\n")
   -> 0.0007s
-- execute("DROP FUNCTION IF EXISTS delete_user_password;\n")
rake aborted!
StandardError: Er is een fout opgetreden, deze en alle latere migraties zijn geannuleerd: (StandardError)

PG::DependentObjectsStillExist: ERROR:  kan functie delete_user_password() niet verwijderen omdat andere objecten ervan afhankelijk zijn
DETAIL:  trigger users_password_sync_on_delete_password on table backup.users depends on function delete_user_password()
HINT:  Gebruik DROP ... CASCADE om ook de afhankelijke objecten te verwijderen.
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-4.0.0/lib/patches/db/pg/alias_method.rb:109:in `exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-4.0.0/lib/patches/db/pg/alias_method.rb:109:in `async_exec'
(evaluatie op /var/www/discourse/lib/method_profiler.rb:38):24:in `async_exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:56:in `block (2 levels) in raw_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract_adapter.rb:1004:in `block in with_raw_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract_adapter.rb:976:in `with_raw_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:55:in `block in raw_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/notifications/instrumenter.rb:58:in `instrument'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract_adapter.rb:1119:in `log'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:54:in `raw_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/database_statements.rb:538:in `internal_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/database_statements.rb:137:in `execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/query_cache.rb:27:in `execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:48:in `execute'

Dus ik deed een restore --pause en probeerde de migraties vanuit een andere terminal als volgt:

rake db:ensure_post_migrations db:migrate

Daarna deed ik iets als dit:

ActiveRecord::Base.connection.execute(<<~SQL)
  DROP TRIGGER IF EXISTS users_after_delete_user_passwords ON users;
SQL

ActiveRecord::Base.connection.execute(<<~SQL)
  DROP TRIGGER IF EXISTS users_password_sync_on_delete_password ON users;
SQL

ActiveRecord::Base.connection.execute(<<~SQL)
  DROP TRIGGER IF EXISTS users_password_sync_on_delete_password ON backup.users;
SQL

En uiteindelijk kreeg ik de migratie voltooid.
Hopelijk kan ik het morgen opnieuw doen met een nieuwe database. . .

1 like
3

You have tables in the backup schema (used during backups/restores) that depend on this function.

Is the backup schema here stale? If so you probably need only DROP SCHEMA backup here to get rid of it.

1 like
4

Thanks very much! That sounds right, but when I do that I get stuff like :slight_smile:

table backup.group_archived_messages depends on schema backup
table backup.incoming_emails depends on schema backup
table backup.user_options depends on schema backup
table backup.email_change_requests depends on schema backup
table backup.given_daily_likes depends on schema backup
table backup.onceoff_logs depends on schema backup
table backup.tags depends on schema backup
table backup.topic_tags depends on schema backup
table backup.tag_users depends on schema backup
table backup.category_tags depends on schema backup
table backup.scheduler_stats depends on schema backup
table backup.tag_groups depends on schema backup

This was a fresh/empty database when I started, so I"m confused why I have a stale backup database.

EDIT: I used cascade, like it told me:

DROP SCHEMA backup CASCADE;

I’m guessing that solved it! It’ll be 25 minutes before I know and hopefully I’ll have stopped looking at a computer by then.

I’ll report back tomorrow.

Thanks again.

1 like
5

That was it. I am 99% sure that I’d stopped a restore with control-c for some reason (like it takes 25 minutes) and that left behind the stale schema. I can’t believe this isn’t something I have managed to learn in the paste decade, but so it is!

Thanks very much.

1 like
6

Dit onderwerp is automatisch gesloten 30 dagen na het laatste antwoord. Nieuwe antwoorden zijn niet meer toegestaan.