Follow-up from "Add existence checks around todos migration to ensure it is idempotent"
The following discussion from gitlab-ce!20543 should be addressed:
- [ ] @nolith started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20543#note_87293635): (+3 comments)
> @stanhu I'm not sure about this.
>
> If we follow what you suggested in https://gitlab.com/gitlab-com/infrastructure/issues/4555#note_87200871 we will be able to deploy immediately, picking this requires waiting for the 12h QA windows for RC7 on staging, and we also have gcp_migration failover test tomorrow.
`stanhu`
> Right, I think we'll want this regardless of what we do since this migration can fail partway through.
`nolith`
> yes, good point.
>
> @yorickpeterse was also concerned about the content of the down method gitlab-com/infrastructure#4555
`stanhu`
> Yeah, that is a separate issue indeed.
@yorickpeterse said
> The rollback procedure is also problematic, as it performs operations that will lock the entire table (e.g. removing the index), and heavy writes (removing all todos with a NULL project ID, without any batching).
issue