Feature request: make add/remove concurrent index work together in a single "change" migration

[Dillon Welch]

To properly set up a concurrent index migration that can be rolled back, it looks like this:

class AddUserEmailIndex < ActiveRecord::Migration[5.2]
  disable_ddl_transaction!

  def up
    safe_add_concurrent_index :users, :email, unique: true
  end

  def down
    safe_remove_concurrent_index :users, :email, unique: true
  end
end

IMO, ideally it would look like this

class AddUserEmailIndex < ActiveRecord::Migration[5.2]
  disable_ddl_transaction!

  def change
    safe_add_concurrent_index :users, :email, unique: true
  end
end

and the gem would be smart enough to run safe_remove_concurrent_index on the rollback without needing separate up/down methods.

[Jon Radon]

We're concurrently creating the index, which means that it does not block during index creation. To accomplish what you're suggesting, I think pg_ha_migrations would have to monitor the concurrent index creation process, blocking while that happens, and then if it fails issue the remove. If that's the case, I'd hesitate to add that kind of tracking logic into the gem.

For some context, we purposely use concurrent index creation so that we don't have to wait until the index is completed. Large indexes can take a long time to build. For large indexes, we generally deploy the migration and then later enable the code that depends on the index.

Let me know if this helps or if my intuition about this is off base.

[Dillon Welch]

My request was just to be able to roll back the index without needing separate up/down methods. Based on the response to #3, it looks like that's not going to be supported.

[Jon Radon]

Correct, most likely not.

I was also incorrect in my last comment. Ruby does synchronously run concurrent index creation. Thanks @jcoleman for pointing it out. Either way though, it's probably outside of the philosophy we're trying to adhere to with the gem.