Skip to content

Create routing table for ci_builds

Marius Bobin requested to merge 382033-create-p-ci-builds into master

What does this MR do and why?

Related to #382033 (closed)

It creates the routing table for ci_builds and attaches ci_builds as its first partition: https://docs.gitlab.com/ee/development/database/table_partitioning.html#step-6---create-parent-table-and-attach-existing-table-as-the-initial-partition

What can go wrong

During deployment we need to lock "ci_stages", "ci_resource_groups", "ci_pipelines", "ci_builds" tables in access exclusive mode and they are the most used tables in the application. We need to lock them in the same way that the application uses them, otherwise the migration will create deadlock errors. But after a few experiments we are confident in the locking order.

The execution could overlap with on the autovacuum wraparound processes and fail to get the locks since that process doesn't interrupt itself. This thanos query can be check to see if there is a current vacuum running on one of the tables, but unfortunately it doesn't export the type of vacuum running, so it might be just a regular vacuum. But this query can be used on the primary CI database to check for wraparound vacuum:

select query, age(clock_timestamp(), query_start) as duration from postgres_pg_stat_activity_autovacuum()  WHERE query ILIKE '%wraparound%';

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 Marius Bobin

Merge request reports