PG::DependentObjectsStillExist: ERROR: cannot drop function delete_user_password() because other objects depend on it
似乎来自这里：
这是一个迁移后：
== 20240910090759 MakePasswordColumnsFromUsersReadOnly: migrating =============
-- 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: An error has occurred, this and all later migrations canceled: (StandardError)
PG::DependentObjectsStillExist: ERROR: cannot drop function delete_user_password() because other objects depend on it
DETAIL: trigger users_password_sync_on_delete_password on table backup.users depends on function delete_user_password()
HINT: Use DROP ... CASCADE to drop the dependent objects too.
/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'
(eval at /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'
1 个赞
您在 backup schema（备份/恢复期间使用）中有表依赖于此函数。
这里的 backup schema 是否已过时？如果是，您可能只需要在此处 DROP SCHEMA backup 来摆脱它。
1 个赞
非常感谢！听起来是正确的，但当我这样做时，我会得到类似这样的结果 
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
当我开始时，这是一个全新的/空的数据库，所以我很困惑为什么我有一个过时的备份数据库。
编辑：我使用了 cascade，就像它告诉我的那样：
DROP SCHEMA backup CASCADE;
我猜这解决了问题！需要 25 分钟我才能知道结果，希望到时候我已经停止看电脑了。
我明天会汇报。
再次感谢。
1 个赞
就是这样。我99%确定我曾因为某种原因（比如需要25分钟）用control-c停止了一个恢复过程，然后就留下了这个过时的 schema。真不敢相信这是我过去十年都没学会的东西，但事实就是如此！
非常感谢。
1 个赞
此主题在上次回复后 30 天自动关闭。不再允许回复。