Prepare ci_builds for list partitioning
What does this MR do and why?
It adds the check constraint required for partitioning the table and schedules its async validation. We have a database helper for this, but it validates the constraint synchronously which is a problem for ci_builds
since we can't have long running transactions. The helper will be updated to support async options in: #393395 (closed)
It depends on being merged first: !113725 (merged)
How to set up and validate locally
- Run migrations in the test database:
./scripts/regenerate-schema
- Open a Rails console in the test environment:
bin/rails c -e test
- Execute the validation:
Gitlab::Database::AsyncConstraints::PostgresAsyncConstraintValidation.ordered.check_constraint_type.each { |record| Gitlab::Database::AsyncConstraints::Validators.for(record).perform }
-
ALTER TABLE "ci_builds" VALIDATE CONSTRAINT "partitioning_constraint";
should appear inlog/test.log
- Confirm with the psql console:
gdk psql
\c gitlabhq_test
\d+ ci_builds
- The
NOT VALID
part is no longer present in the check constraint definition:"partitioning_constraint" CHECK (partition_id = 100)
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.
Related to #382033 (closed)
Edited by Marius Bobin