Skip to content

Create time-space partitions in separate schema (2)

Andreas Brandl requested to merge ab/partition-management into master

What does this MR do?

This is a follow-up to !34504 (merged) which got reverted.

For the reasoning behind creating a separate schema for dynamic partitions, please refer to the linked MR and in particular the explanation in !34504 (comment 362737531).

The reason for the revert is outlined in !34504 (comment 363914761). The summary is:

  1. The database backup (triggered through rake) uses pg_dump to copy the database contents to disk
  2. By default, it dumps the full database.
  3. Only when Gitlab.config.backup.pg_schema is set, we target the configured schema only through -n whatever_schema_you_have_set.
  4. In the case of (3), we need to explicitly list all other schemas GitLab owns - this is what we fix in this MR.

This MR contains:

  1. Introducing schema gitlab_partitions_dynamic to hold dynamically managed partitions in the future
  2. Explicitly include said new schema in the backup, if backup.pg_schema is configured explicitly.

In the case of (2), we arrive at something similar to pg_dump --clean -n public -n gitlab_partitions_dynamic $db. This works fine and we have DROP SCHEMA gitlab_partitions_dynamic; ...; CREATE SCHEMA gitlab_partitions_dynamic; in the backup (equivalently for public).

Naming choices

The new schema is called gitlab_partitions_dynamic. The gitlab_ prefix has been chosen to avoid any name clashes in a shared database environment.

This came from seeing gitlab-foss!1345 (merged) which allows to configure the schema the database backup (rake task) dumps to something else than public. I've also anecdotally heard of installations that shared a database for GitLab and other applications.

Therefore, we're making an effort here to be more verbose than we might need to be and include a gitlab_ prefix to schema names.

Does this MR meet the acceptance criteria?

Conformity

Edited by 🤖 GitLab Bot 🤖

Merge request reports