Fix spec failures due to PG::LockNotAvailable errors
We were seeing a high number of transient failures in the migration jobs because `with_lock_retries` leaked non-zero, short `lock_timeout` values (e.g. 100 ms) when used inside a Rails `change` method. If the PostgreSQL autovacuum process happened to be running, it would lock the table that it was vacuuming. During the migration rollback, if the DDL operation needed a lock on the table, the short `lock_timeout` would encounter the existing table lock and fail. Even though `SET LOCAL` was used to ensure `lock_timeout` didn't leak outside of the current transaction, the parent transaction would still retain that value. To avoid this issue, we should define separate `up` and `down` methods so that we don't rely on the Rails magic to reverse a migration. This ensures lock retries are used properly in both directions and prevents `lock_timeout` from leaking during a migration rollback. Closes https://gitlab.com/gitlab-org/gitlab/-/issues/207088
Showing
Please register or sign in to comment