Avoiding Sub-transactions in Automatic Locking Writes on newly created tables
As part of the MR we introduced a new version of database migrations that automatically locks tables on the databases where they don't belong on a decomposed database setup. gitlab_main
tables are locked on the ci
database, and the other way around.
This functionality is controlled via an ops
Feature Flag: automatic_lock_writes_on_table
.
When the FF has been enabled on production
on 12th December, and a merge request that contains a new table database migration, it has caused a sub-transaction due to calling the lock_retries
twice.
The FF has been reverted to false
on both environments staging
and production
to mitigate the issue, until this one is resolved. The FF is already set to false
by default for any other environments.
Updates
- The related MR has been merged: !106872 (merged)
- The FF
automatic_lock_writes_on_table
has been enabled onstaging
on 9th January. Until we verify that at least one table has been created and locked for writes, with no problem. Then we can enable the feature flag onproduction
again - On 20th January a new table has been created and successfully locked on staging CI database
namespaces_storage_limit_exclusions
, with this MR: !108449 (merged). The feature flagautomatic_lock_writes_on_table
to be enabled on production later - I enabled the feature flag
automatic_lock_writes_on_table
onproduction
on the 20th January - The table
namespaces_storage_limit_exclusions
has been successfully created onproduction
and locked on theci
database
Edited by Omar Qunsul