change_column_null (without 4th argument) still locks postgres about strong_migrations HOT 5 CLOSED

Hey @ABewsher, which version of Postgres are you on?

I imagine adding an index would make it faster, but I'd try it on a staging database first. You could also try the approach outlined here, but I haven't tried it myself, and seems like it carries a small performance penalty (slows future writes by 0.5%-1%).

If the index approach works, I think that's a better recommendation since Rails has built-in support for those commands (don't need to use execute) and schema.rb can be dumped properly.

from strong_migrations.

In general, I'm a fan of having minimal constraints on the database (unique indexes, but no foreign keys or not null), but I understand not everyone takes that view.

from strong_migrations.

Thanks for your prompt reply @ankane

pg gem version 1.1.4
Postgres 10.7

For now we're just not bothering with the constraint. We did test this on staging before deploying to production, but we'll need more record to test it properly it seems. ;-)

If we do try again on staging (with 7M new records), I'll let you know if the index helps.

from strong_migrations.

Sounds good

from strong_migrations.

Then I ran this:

class AddNullFalseToUserVisibleInEvents < ActiveRecord::Migration[5.1]
def change
change_column_null(:events, :user_visible, false)
end
end
... and it locked the DB 👎

Note that I have not used the 4th argument but it was still "dangerous".

Regardless of what I end up doing, this could still do with a warning as even without the 4th argument it still locked things up.

from strong_migrations.