Obscure WTF error message running migrations for 3.1

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: [2] <- 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: [2] -> 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@'%'```

Good catch, the message is wrong. I have proposed a fix

so that the message would be:

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 Mastodon
database (mastodon_development) using a super user and running:
         
    ALTER USER indie WITH SUPERUSER
      
The query 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).

Can you try this code on your fork and see if it gets better?

After this, you can temporarily give user indie superuser rights and revoke them after the migration is done via

    ALTER USER indie WITH NOSUPERUSER

As I mentioned in the post, the user “indie” is already superuser on the DB in my testing area postgres setup, and this command did not work.

Something in the migrations is broken afaict.

Can you show me the rights on the database and schema level in PostgreSQL?