Create time-space partitions in separate schema (2)
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:
- The database backup (triggered through rake) uses
pg_dump
to copy the database contents to disk - By default, it dumps the full database.
- Only when
Gitlab.config.backup.pg_schema
is set, we target the configured schema only through-n whatever_schema_you_have_set
. - 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:
- Introducing schema
gitlab_partitions_dynamic
to hold dynamically managed partitions in the future - 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.