Update with_lock_retries V2 helper to not nest WithLockRetries
What does this MR do and why?
We can now enable lock retries at transaction level with enable_lock_retries!
. When done for transactional migrations that use helpers which call with_lock_retries
internally an error will be raised, for example
with_lock_retries can not be run inside an already open transaction
Use migration-level lock retries instead, see https://docs.gitlab.com/ee/development/migration_style_guide.html#retry-mechanism-when-acquiring-database-locks
This MR updates with_lock_retries
V2, when called inside open transaction, to check if lock retires are already enabled, and if yes to execute the provided code block directly, and raise the error if not.
How to set up and validate locally
create table example (id serial primary key);
This migration will succeed:
class TestMigration1 < Gitlab::Database::Migration[1.0]
enable_lock_retries!
def up
with_lock_retries do
execute 'LOCK TABLE example in EXCLUSIVE MODE'
puts 'locked!'
end
end
def down
puts 'DOWN'
end
end
while this one will raise an error
class TestMigration2 < Gitlab::Database::Migration[1.0]
def up
with_lock_retries do
execute 'LOCK TABLE example in EXCLUSIVE MODE'
puts 'locked!'
end
end
def down
puts 'DOWN'
end
end
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Andreas Brandl