I’m trying to build 3.1 on my local machine to ensure it will duplicate on my server. However, after trying 5 different times, it still does not work.
psql (10.9 (Ubuntu 10.9-0ubuntu0.18.10.1)) Type "help" for help.
I’m building off my branch and restoring the prod db. Everything works fine until I try to run the post-restoration migration. I’m including the tail of the output from pg_restore, and the error from the migration.
The “database user” error is wrong, WTF is this “log into Gitlab” stuff?
Also note that the user I ran this command with is already superuser in postgres.
indie@ecosteaderhost:~/mastodev/masto_3/mastodon$ RAILS_ENV=development bundle exec rails db:migrate (0.2ms) SELECT pg_try_advisory_lock(xxxxxxxxxxxxxxxxxxxxx) (0.6ms) SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC Migrating to IncreaseBackupSize (20191212003415) Chewy strategies stack:  <- bypass @ /home/indie/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/chewy-5.1.0/lib/chewy/railtie.rb:37 == 20191212003415 IncreaseBackupSize: migrating =============================== -- transaction_open?() -> 0.0000s Mastodon::MigrationHelpers::Grant Exists (1.6ms) SELECT 1 AS one FROM "information_schema"."role_table_grants" WHERE "information_schema"."role_table_grants"."privilege_type" = $1 AND "information_schema"."role_table_grants"."table_name" = $2 AND (grantee = user) LIMIT $3 [["privilege_type", "TRIGGER"], ["table_name", "backups"], ["LIMIT", 1]] Chewy strategies stack:  -> bypass, now bypass @ /home/indie/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/chewy-5.1.0/lib/chewy/railtie.rb:37 (0.2ms) SELECT pg_advisory_unlock(xxxxxxxxxxxxxxxxxxx426479xx) rails aborted! StandardError: An error has occurred, all later migrations canceled: Your database user is not allowed to create, drop, or execute triggers on the table backups. If you are using PostgreSQL you can solve this by logging in to the GitLab database (mastodon_development) using a super user and running: ALTER USER indie WITH SUPERUSER For MySQL you instead need to run: GRANT ALL PRIVILEGES ON *.* TO indie@'%' Both queries will grant the user super user permissions, ensuring you don't run into similar problems in the future (e.g. when new tables are created). /home/indie/mastodev/masto_3/mastodon/lib/mastodon/migration_helpers.rb:885:in `check_trigger_permissions!' /home/indie/mastodev/masto_3/mastodon/lib/mastodon/migration_helpers.rb:484:in `rename_column_concurrently' /home/indie/mastodev/masto_3/mastodon/lib/mastodon/migration_helpers.rb:548:in `change_column_type_concurrently' /home/indie/mastodev/masto_3/mastodon/db/migrate/20191212003415_increase_backup_size.rb:10:in `block in up' /home/indie/mastodev/masto_3/mastodon/db/migrate/20191212003415_increase_backup_size.rb:9:in `up' bin/rails:4:in `<main>' Caused by: Your database user is not allowed to create, drop, or execute triggers on the table backups. If you are using PostgreSQL you can solve this by logging in to the GitLab database (mastodon_development) using a super user and running: ALTER USER indie WITH SUPERUSER For MySQL you instead need to run: GRANT ALL PRIVILEGES ON *.* TO indie@'%'```