You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is meant to be a cautionary tale for other users, maybe it can be a documentation change once we agree on how this should be presented. The index reapplication worked as expected, keeping only the appropriate indexes after the update. I then noticed a mistake and rolled back the migration before fixing it and migrating again, the "fix" allowed an index that was dropped previously to stay, but it was no longer on the DB because it was dropped earlier. The add_index call was many migrations back, even worse this was the unique index, needed for my periodic refresh_materialized_view with concurrently: true call.
This is meant to be a cautionary tale for other users, maybe it can be a documentation change once we agree on how this should be presented. The index reapplication worked as expected, keeping only the appropriate indexes after the update. I then noticed a mistake and rolled back the migration before fixing it and migrating again, the "fix" allowed an index that was dropped previously to stay, but it was no longer on the DB because it was dropped earlier. The
add_index
call was many migrations back, even worse this was the unique index, needed for my periodicrefresh_materialized_view
withconcurrently: true
call.I had to manually run:
Possible workarounds?
update_view
whitelist which indexes can be dropped (less magic) but less prone for errors.update_view
scream (maybe it did, but I didn't notice) when dropping an index.update_view
save the dropped index, to be created when rolling back? This one I have no idea on how it would workThe text was updated successfully, but these errors were encountered: