Apply 4 suggestion(s) to 2 file(s)

doc/install/postgresql_extensions.md

@@ -56,8 +56,8 @@ On some systems you may need to install an additional package (for example,
 
 ## Typical failure scenarios
 
-The following is an example of a new GitLab installation failing because the extension hasn't been installed
-first.
+The following is an example of a new GitLab installation failing because the extension hasn't been
+installed first.
 
 ```shell
 ---- Begin output of "bash"  "/tmp/chef-script20210513-52940-d9b1gs" ----
@@ -91,8 +91,8 @@ This query will grant the user superuser permissions, ensuring any database exte
 can be installed through migrations.
 ```
 
-In order to recover from failed migrations, the extension needs to be installed manually using a superuser, and
-the GitLab upgrade completed by [re-running the database migrations](../administration/raketasks/maintenance.md#run-incomplete-database-migrations):
+To recover from failed migrations, the extension must be installed manually by a superuser, and the
+GitLab upgrade completed by [re-running the database migrations](../administration/raketasks/maintenance.md#run-incomplete-database-migrations):
 
 ```shell
 sudo gitlab-rake db:migrate

doc/install/requirements.md

@@ -143,21 +143,28 @@ but we can't guarantee compatibility.
 
 #### Exclusive use of GitLab databases
 
-Databases created or used for GitLab, Geo, Gitaly Cluster or other components
-should be for the exclusive use of GitLab. Do not make direct changes to the database,
-schemas, users or other properties except when following procedures in the GitLab documentation
-or following the directions of GitLab Support or other GitLab engineers.
-
-- The main GitLab application currently uses three schemas: the default `public` schema, plus it
-will automatically create `gitlab_partitions_static` and `gitlab_partitions_dynamic`.
-No other schemas should be manually created.
-- GitLab may create new schemas as part of Rails database migrations. This will happen when performing
-a GitLab upgrade. The GitLab database account requires access to do this.
-- GitLab creates and modifies tables during the upgrade process, and also as part
-of normal operations to manage partitioned tables.
-- You should not modify the GitLab schema, for example adding triggers, modifying tables.
-Database migrations are tested against the schema definition in the GitLab code base. GitLab version
-upgrades may fail if the schema is modified.
+Databases created or used for GitLab, Geo, Gitaly Cluster, or other components should be for the
+exclusive use of GitLab. Do not make direct changes to the database, schemas, users, or other
+properties except when following procedures in the GitLab documentation or following the directions
+of GitLab Support or other GitLab engineers.
+
+- The main GitLab application currently uses three schemas:
+
+  - The default `public` schema
+  - `gitlab_partitions_static` (automatically created)
+  - `gitlab_partitions_dynamic` (automatically created)
+
+  No other schemas should be manually created.
+
+- GitLab may create new schemas as part of Rails database migrations. This happens when performing
+  a GitLab upgrade. The GitLab database account requires access to do this.
+
+- GitLab creates and modifies tables during the upgrade process, and also as part of normal
+  operations to manage partitioned tables.
+
+- You should not modify the GitLab schema (for example, adding triggers or modifying tables).
+  Database migrations are tested against the schema definition in the GitLab code base. GitLab
+  version upgrades may fail if the schema is modified.
 
 ## Puma settings