Merge branch 'update-docs-remove-postgres-9-10' into 'master'

Update documentation for the PostgreSQL 9.6 and 10 removals

Closes omnibus-gitlab#5101

See merge request gitlab-org/gitlab!31240

README.md

@@ -82,7 +82,7 @@ GitLab is a Ruby on Rails application that runs on the following software:
 - Ruby (MRI) 2.6.5
 - Git 2.8.4+
 - Redis 2.8+
-- PostgreSQL 9.6+
+- PostgreSQL 11+
 
 For more information please see the [architecture](https://docs.gitlab.com/ee/development/architecture.html) and [requirements](https://docs.gitlab.com/ee/install/requirements.html) documentation.
 

doc/administration/database_load_balancing.md

@@ -26,9 +26,9 @@ sent to the primary (unless necessary), the primary (`db3`) hardly has any load.
 
 ## Requirements
 
-For load balancing to work you will need at least PostgreSQL 9.2 or newer,
+For load balancing to work you will need at least PostgreSQL 11 or newer,
 [**MySQL is not supported**](../install/requirements.md#database). You also need to make sure that you have
-at least 1 secondary in [hot standby](https://www.postgresql.org/docs/9.6/hot-standby.html) mode.
+at least 1 secondary in [hot standby](https://www.postgresql.org/docs/11/hot-standby.html) mode.
 
 Load balancing also requires that the configured hosts **always** point to the
 primary, even after a database failover. Furthermore, the additional hosts to

doc/administration/geo/replication/database.md

@@ -33,9 +33,9 @@ recover. See below for more details.
 
 The following guide assumes that:
 
-- You are using Omnibus and therefore you are using PostgreSQL 9.6 or later
-  which includes the [`pg_basebackup` tool](https://www.postgresql.org/docs/9.6/app-pgbasebackup.html) and improved
-  [Foreign Data Wrapper](https://www.postgresql.org/docs/9.6/postgres-fdw.html) support.
+- You are using Omnibus and therefore you are using PostgreSQL 11 or later
+  which includes the [`pg_basebackup` tool](https://www.postgresql.org/docs/11/app-pgbasebackup.html) and improved
+  [Foreign Data Wrapper](https://www.postgresql.org/docs/11/postgres-fdw.html) support.
 - You have a **primary** node already set up (the GitLab server you are
   replicating from), running Omnibus' PostgreSQL (or equivalent version), and
   you have a new **secondary** server set up with the same versions of the OS,
@@ -160,7 +160,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    `postgresql['md5_auth_cidr_addresses']` and `postgresql['listen_address']`.
 
    The `listen_address` option opens PostgreSQL up to network connections with the interface
-   corresponding to the given address. See [the PostgreSQL documentation](https://www.postgresql.org/docs/9.6/runtime-config-connection.html)
+   corresponding to the given address. See [the PostgreSQL documentation](https://www.postgresql.org/docs/11/runtime-config-connection.html)
    for more details.
 
    Depending on your network configuration, the suggested addresses may not
@@ -213,7 +213,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    ```
 
    You may also want to edit the `wal_keep_segments` and `max_wal_senders` to match your
-   database replication requirements. Consult the [PostgreSQL - Replication documentation](https://www.postgresql.org/docs/9.6/runtime-config-replication.html)
+   database replication requirements. Consult the [PostgreSQL - Replication documentation](https://www.postgresql.org/docs/11/runtime-config-replication.html)
    for more information.
 
 1. Save the file and reconfigure GitLab for the database listen changes and
@@ -442,7 +442,7 @@ data before running `pg_basebackup`.
      (e.g., you know the network path is secure, or you are using a site-to-site
      VPN). This is **not** safe over the public Internet!
    - You can read more details about each `sslmode` in the
-     [PostgreSQL documentation](https://www.postgresql.org/docs/9.6/libpq-ssl.html#LIBPQ-SSL-PROTECTION);
+     [PostgreSQL documentation](https://www.postgresql.org/docs/11/libpq-ssl.html#LIBPQ-SSL-PROTECTION);
      the instructions above are carefully written to ensure protection against
      both passive eavesdroppers and active "man-in-the-middle" attackers.
    - Change the `--slot-name` to the name of the replication slot
@@ -464,7 +464,7 @@ high-availability configuration with a cluster of nodes supporting a Geo
 information, see [High Availability with Omnibus GitLab](../../high_availability/database.md#high-availability-with-omnibus-gitlab-premium-only).
 
 For a Geo **secondary** node to work properly with PgBouncer in front of the database,
-it will need a separate read-only user to make [PostgreSQL FDW queries](https://www.postgresql.org/docs/9.6/postgres-fdw.html)
+it will need a separate read-only user to make [PostgreSQL FDW queries](https://www.postgresql.org/docs/11/postgres-fdw.html)
 work:
 
 1. On the **primary** Geo database, enter the PostgreSQL on the console as an

doc/administration/geo/replication/external_database.md

@@ -157,7 +157,7 @@ when `roles ['geo_secondary_role']` is set. For high availability,
 refer to [Geo High Availability](../../reference_architectures/index.md).
 If you want to run this database external to Omnibus, please follow the instructions below.
 
-The tracking database requires an [FDW](https://www.postgresql.org/docs/9.6/postgres-fdw.html)
+The tracking database requires an [FDW](https://www.postgresql.org/docs/11/postgres-fdw.html)
 connection with the **secondary** replica database for improved performance.
 
 If you have an external database ready to be used as the tracking database,
@@ -211,7 +211,7 @@ the tracking database on port 5432.
    gitlab-rake geo:db:migrate
    ```
 
-1. Configure the [PostgreSQL FDW](https://www.postgresql.org/docs/9.6/postgres-fdw.html)
+1. Configure the [PostgreSQL FDW](https://www.postgresql.org/docs/11/postgres-fdw.html)
    connection and credentials:
 
    Save the script below in a file, ex. `/tmp/geo_fdw.sh` and modify the connection

doc/administration/geo/replication/index.md

@@ -110,7 +110,7 @@ The following are required to run Geo:
   The following operating systems are known to ship with a current version of OpenSSH:
   - [CentOS](https://www.centos.org) 7.4+
   - [Ubuntu](https://ubuntu.com) 16.04+
-- PostgreSQL 9.6+ with [FDW](https://www.postgresql.org/docs/9.6/postgres-fdw.html) support and [Streaming Replication](https://wiki.postgresql.org/wiki/Streaming_Replication)
+- PostgreSQL 11+ with [FDW](https://www.postgresql.org/docs/11/postgres-fdw.html) support and [Streaming Replication](https://wiki.postgresql.org/wiki/Streaming_Replication)
 - Git 2.9+
 - All nodes must run the same GitLab version.
 

doc/administration/geo/replication/security_review.md

@@ -177,7 +177,7 @@ from [owasp.org](https://owasp.org/).
 
 ### What databases and application servers support the application?
 
-- PostgreSQL >= 9.6, Redis, Sidekiq, Puma.
+- PostgreSQL >= 11, Redis, Sidekiq, Puma.
 
 ### How will database connection strings, encryption keys, and other sensitive components be stored, accessed, and protected from unauthorized detection?
 

doc/administration/gitaly/praefect.md

@@ -56,7 +56,7 @@ for improvements including
 The minimum recommended configuration for a Gitaly Cluster requires:
 
 - 1 highly available load balancer
-- 1 highly available PostgreSQL server (PostgreSQL 9.6 or newer)
+- 1 highly available PostgreSQL server (PostgreSQL 11 or newer)
 - 3 Praefect nodes
 - 3 Gitaly nodes (1 primary, 2 secondary)
 
@@ -82,7 +82,7 @@ package (highly recommended), follow the steps below:
 Before beginning, you should already have a working GitLab instance. [Learn how
 to install GitLab](https://about.gitlab.com/install/).
 
-Provision a PostgreSQL server (PostgreSQL 9.6 or newer). Configuration through
+Provision a PostgreSQL server (PostgreSQL 11 or newer). Configuration through
 the Omnibus GitLab distribution is not yet supported. Follow this
 [issue](https://gitlab.com/gitlab-org/gitaly/issues/2476) for updates.
 
@@ -138,7 +138,7 @@ of GitLab and should not be replicated.
 To complete this section you will need:
 
 - 1 Praefect node
-- 1 PostgreSQL server (PostgreSQL 9.6 or newer)
+- 1 PostgreSQL server (PostgreSQL 11 or newer)
   - An SQL user with permissions to create databases
 
 During this section, we will configure the PostgreSQL server, from the Praefect

doc/administration/high_availability/database.md

@@ -969,7 +969,7 @@ repmgr['trust_auth_cidr_addresses'] = %w(192.168.1.44/32 db2.example.com)
 ##### MD5 Authentication
 
 If you are running on an untrusted network, repmgr can use md5 authentication
-with a [`.pgpass` file](https://www.postgresql.org/docs/9.6/libpq-pgpass.html)
+with a [`.pgpass` file](https://www.postgresql.org/docs/11/libpq-pgpass.html)
 to authenticate.
 
 You can specify by IP address, FQDN, or by subnet, using the same format as in

doc/administration/high_availability/pgbouncer.md

@@ -215,7 +215,7 @@ To start a session, run
 ```shell
 # gitlab-ctl pgb-console
 Password for user pgbouncer:
-psql (9.6.8, server 1.7.2/bouncer)
+psql (11.7, server 1.7.2/bouncer)
 Type "help" for help.
 
 pgbouncer=#

doc/ci/docker/using_docker_images.md

@@ -209,7 +209,7 @@ default:
   image: ruby:2.6
 
   services:
-    - postgres:9.3
+    - postgres:11.7
 
   before_script:
     - bundle install
@@ -235,14 +235,14 @@ default:
 test:2.6:
   image: ruby:2.6
   services:
-  - postgres:9.3
+  - postgres:11.7
   script:
   - bundle exec rake spec
 
 test:2.7:
   image: ruby:2.7
   services:
-  - postgres:9.4
+  - postgres:12.2
   script:
   - bundle exec rake spec
 ```
@@ -257,7 +257,7 @@ default:
     entrypoint: ["/bin/bash"]
 
   services:
-  - name: my-postgres:9.4
+  - name: my-postgres:11.7
     alias: db-postgres
     entrypoint: ["/usr/local/bin/db-postgres"]
     command: ["start"]
@@ -289,7 +289,7 @@ variables:
   POSTGRES_INITDB_ARGS: "--encoding=UTF8 --data-checksums"
 
 services:
-- name: postgres:9.4
+- name: postgres:11.7
   alias: db
   entrypoint: ["docker-entrypoint.sh"]
   command: ["postgres"]

doc/development/filtering_by_label.md

@@ -80,7 +80,7 @@ it did not improve query performance.
 ## Attempt B: Denormalize using an array column
 
 Having [removed MySQL support in GitLab 12.1](https://about.gitlab.com/blog/2019/06/27/removing-mysql-support/),
-using [PostgreSQL's arrays](https://www.postgresql.org/docs/9.6/arrays.html) became more
+using [PostgreSQL's arrays](https://www.postgresql.org/docs/11/arrays.html) became more
 tractable as we didn't have to support two databases. We discussed denormalizing
 the `label_links` table for querying in
 [issue #49651](https://gitlab.com/gitlab-org/gitlab-foss/issues/49651),
@@ -91,7 +91,7 @@ and `epics`: `issues.label_ids` would be an array column of label IDs, and
 `issues.label_titles` would be an array of label titles.
 
 These array columns can be complemented with [GIN
-indexes](https://www.postgresql.org/docs/9.6/gin-intro.html) to improve
+indexes](https://www.postgresql.org/docs/11/gin-intro.html) to improve
 matching.
 
 ### Attempt B1: store label IDs for each object

doc/development/geo.md

@@ -216,15 +216,11 @@ bundle exec rake geo:db:migrate
 Foreign Data Wrapper ([FDW](#fdw)) is used by the [Geo Log Cursor](#geo-log-cursor) and improves
 the performance of many synchronization operations.
 
-FDW is a PostgreSQL extension ([`postgres_fdw`](https://www.postgresql.org/docs/current/postgres-fdw.html)) that is enabled within
+FDW is a PostgreSQL extension ([`postgres_fdw`](https://www.postgresql.org/docs/11/postgres-fdw.html)) that is enabled within
 the Geo Tracking Database (on a **secondary** node), which allows it
 to connect to the readonly database replica and perform queries and filter
 data from both instances.
 
-While FDW is available in older versions of PostgreSQL, we needed to
-raise the minimum required version to 9.6 as this includes many
-performance improvements to the FDW implementation.
-
 This persistent connection is configured as an FDW server
 named `gitlab_secondary`. This configuration exists within the database's user
 context only. To access the `gitlab_secondary`, GitLab needs to use the

doc/development/namespaces_storage_statistics.md

@@ -38,7 +38,7 @@ alternative method.
 
 ### Attempt A: PostgreSQL materialized view
 
-Model can be updated through a refresh strategy based on a project routes SQL and a [materialized view](https://www.postgresql.org/docs/9.6/rules-materializedviews.html):
+Model can be updated through a refresh strategy based on a project routes SQL and a [materialized view](https://www.postgresql.org/docs/11/rules-materializedviews.html):
 
 ```sql
 SELECT split_part("rs".path, '/', 1) as root_path,

doc/development/verifying_database_capabilities.md

@@ -12,7 +12,7 @@ To facilitate this we have the following methods that you can use:
 This allows you to write code such as:
 
 ```ruby
-if Gitlab::Database.version.to_f >= 9.6
+if Gitlab::Database.version.to_f >= 11.7
   run_really_fast_query
 else
   run_fast_query

doc/install/requirements.md

@@ -174,7 +174,7 @@ If you are using [GitLab Geo](../development/geo.md):
 - The
   [tracking database](../development/geo.md#using-the-tracking-database)
   requires the
-  [postgres_fdw](https://www.postgresql.org/docs/9.6/postgres-fdw.html)
+  [postgres_fdw](https://www.postgresql.org/docs/11/postgres-fdw.html)
   extension.
 
 ```sql

doc/topics/autodevops/customize.md

@@ -353,7 +353,7 @@ The following table lists variables related to the database.
 | `POSTGRES_USER`                         | The PostgreSQL user. Defaults to `user`. Set it to use a custom username. |
 | `POSTGRES_PASSWORD`                     | The PostgreSQL password. Defaults to `testing-password`. Set it to use a custom password. |
 | `POSTGRES_DB`                           | The PostgreSQL database name. Defaults to the value of [`$CI_ENVIRONMENT_SLUG`](../../ci/variables/README.md#predefined-environment-variables). Set it to use a custom database name. |
-| `POSTGRES_VERSION`                      | Tag for the [`postgres` Docker image](https://hub.docker.com/_/postgres) to use. Defaults to `9.6.2`. |
+| `POSTGRES_VERSION`                      | Tag for the [`postgres` Docker image](https://hub.docker.com/_/postgres) to use. Defaults to `11.7`. |
 
 ### Disable jobs
 

doc/topics/autodevops/stages.md

@@ -346,7 +346,7 @@ version of the PostgreSQL chart that supports Kubernetes 1.16 and higher:
 1. Set the:
 
    - `AUTO_DEVOPS_POSTGRES_CHANNEL` variable to `2`.
-   - `POSTGRES_VERSION` variable to `9.6.16` or higher.
+   - `POSTGRES_VERSION` variable to `11.7` or higher.
 
 DANGER: **Danger:** Opting into `AUTO_DEVOPS_POSTGRES_CHANNEL` version `2` deletes
 the version `1` PostgreSQL database. Follow the

doc/topics/autodevops/upgrading_postgresql.md

@@ -173,7 +173,7 @@ TIP: **Tip:** You can also
    PostgreSQL.
 1. Set `AUTO_DEVOPS_POSTGRES_DELETE_V1` to a non-empty value. This flag is a
    safeguard to prevent accidental deletion of databases.
-1. Set `POSTGRES_VERSION` to `9.6.16`. This is the minimum PostgreSQL
+1. Set `POSTGRES_VERSION` to `11.7`. This is the minimum PostgreSQL
    version supported.
 1. Set `PRODUCTION_REPLICAS` to `0`. For other environments, use
    `REPLICAS` with an [environment scope](../../ci/environments.md#scoping-environments-with-specs).

doc/user/clusters/crossplane.md

@@ -167,7 +167,7 @@ metadata:
 specTemplate:
   writeConnectionSecretsToNamespace: gitlab-managed-apps
   forProvider:
-    databaseVersion: POSTGRES_9_6
+    databaseVersion: POSTGRES_11_7
     region: $REGION
     settings:
       tier: db-custom-1-3840
@@ -189,7 +189,7 @@ metadata:
 specTemplate:
   writeConnectionSecretsToNamespace: gitlab-managed-apps
   forProvider:
-    databaseVersion: POSTGRES_9_6
+    databaseVersion: POSTGRES_11_7
     region: $REGION
     settings:
       tier: db-custom-1-3840