Skip to content

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.

Edited by Andreas Brandl

Merge request reports

Loading