Merge branch 'eread/add-postgres-to-subs-rule' into 'master'

Add postgres to Vale substitutions rule

See merge request gitlab-org/gitlab!27764

doc/.vale/gitlab/Substitutions.yml

@@ -3,7 +3,7 @@
 #
 # For a list of all options, see https://errata-ai.github.io/vale/styles/
 extends: substitution
-message: Use "%s" instead of "%s".
+message: 'Use "%s" instead of "%s".'
 link: https://about.gitlab.com/handbook/communication/#top-misused-terms
 level: error
 ignorecase: true
@@ -11,3 +11,4 @@ swap:
   GitLabber: GitLab team member
   self hosted: self-managed
   self-hosted: self-managed
+  postgres: PostgreSQL

doc/administration/audit_events.md

@@ -134,7 +134,7 @@ on adding these events into GitLab:
 
 The current architecture of audit events is not prepared to receive a very high amount of records.
 It may make the user interface for your project or audit logs very busy, and the disk space consumed by the
-`audit_events` Postgres table will increase considerably. It's disabled by default
+`audit_events` PostgreSQL table will increase considerably. It's disabled by default
 to prevent performance degradations on GitLab instances with very high Git write traffic.
 
 In an upcoming release, Audit Logs for Git push events will be enabled

doc/administration/geo/replication/datatypes.md

@@ -21,9 +21,9 @@ verification methods:
 | Database | Application data in PostgreSQL                | Native                                      | Native               |
 | Database | Redis                                         | _N/A_ (*1*)                                 | _N/A_                |
 | Database | Elasticsearch                                 | Native                                      | Native               |
-| Database | Personal snippets                             | Postgres Replication                        | Postgres Replication |
-| Database | Project snippets                              | Postgres Replication                        | Postgres Replication |
-| Database | SSH public keys                               | Postgres Replication                        | Postgres Replication |
+| Database | Personal snippets                             | PostgreSQL Replication                        | PostgreSQL Replication |
+| Database | Project snippets                              | PostgreSQL Replication                        | PostgreSQL Replication |
+| Database | SSH public keys                               | PostgreSQL Replication                        | PostgreSQL Replication |
 | Git      | Project repository                            | Geo with Gitaly                             | Gitaly Checksum      |
 | Git      | Project wiki repository                       | Geo with Gitaly                             | Gitaly Checksum      |
 | Git      | Project designs repository                    | Geo with Gitaly                             | Gitaly Checksum      |

doc/administration/geo/replication/troubleshooting.md

@@ -242,7 +242,7 @@ sudo gitlab-rake gitlab:geo:check
    Checking Geo ... Finished
    ```
 
-   When performing a Postgres major version (9 > 10) update this is expected. Follow:
+   When performing a PostgreSQL major version (9 > 10) update this is expected. Follow:
 
    - [initiate-the-replication-process](database.md#step-3-initiate-the-replication-process)
    - [Geo database has an outdated FDW remote schema](troubleshooting.md#geo-database-has-an-outdated-fdw-remote-schema-error)

doc/administration/high_availability/database.md

@@ -146,7 +146,7 @@ Each service in the package comes with a set of [default ports](https://docs.git
 - Application servers connect to either PgBouncer directly via its [default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#pgbouncer) or via a configured Internal Load Balancer (TCP) that serves multiple PgBouncers.
 - PgBouncer connects to the primary database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
 - Repmgr connects to the database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
-- Postgres secondaries connect to the primary database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
+- PostgreSQL secondaries connect to the primary database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
 - Consul servers and agents connect to each others [Consul default ports](https://docs.gitlab.com/omnibus/package-information/defaults.html#consul)
 
 #### Required information
@@ -899,7 +899,7 @@ after it has been restored to service.
   ```shell
   gitlab-ctl repmgr standby unregister --node=959789412
   ```
-  
+
 ##### Add a node as a standby server
 
   From the stnadby node, run:
@@ -916,24 +916,24 @@ after it has been restored to service.
   scratch by performing a `gitlab-ctl repmgr standby setup NEW_MASTER`.
 
 ##### Add a failed master back into the cluster as a standby node
-  
+
   Once `repmgrd` and PostgreSQL are runnning, the node will need to follow the new
   as a standby node.
-  
+
   ```
   gitlab-ctl repmgr standby follow NEW_MASTER
   ```
-  
+
   Once the node is following the new master as a standby, the node needs to be
   [unregistered from the cluster on the new master node](#remove-a-standby-from-the-cluster).
-  
+
   Once the old master node has been unregistered from the cluster, it will need
   to be setup as a new standby:
-  
+
   ```
   gitlab-ctl repmgr standby setup NEW_MASTER
   ```
-  
+
   Failure to unregister and readd the old master node can lead to subsequent failovers
   not working.
 

doc/administration/high_availability/nfs.md

@@ -132,7 +132,7 @@ across NFS. The GitLab support team will not be able to assist on performance is
 this configuration.
 
 Additionally, this configuration is specifically warned against in the
-[Postgres Documentation](https://www.postgresql.org/docs/current/creating-cluster.html#CREATING-CLUSTER-NFS):
+[PostgreSQL Documentation](https://www.postgresql.org/docs/current/creating-cluster.html#CREATING-CLUSTER-NFS):
 
 >PostgreSQL does nothing special for NFS file systems, meaning it assumes NFS behaves exactly like
 >locally-connected drives. If the client or server NFS implementation does not provide standard file

doc/administration/high_availability/sidekiq.md

@@ -55,7 +55,7 @@ you want using steps 1 and 2 from the GitLab downloads page.
    gitlab_rails['gitaly_token'] = 'YOUR_TOKEN'
    ```
 
-1. Setup Sidekiq's connection to Postgres:
+1. Setup Sidekiq's connection to PostgreSQL:
 
    ```ruby
    gitlab_rails['db_host'] = '10.10.1.30'
@@ -66,7 +66,7 @@ you want using steps 1 and 2 from the GitLab downloads page.
    gitlab_rails['auto_migrate'] = false
    ```
 
-   Remember to add the Sidekiq nodes to the Postgres whitelist:
+   Remember to add the Sidekiq nodes to the PostgreSQL whitelist:
 
    ```ruby
    postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/32 10.10.1.30/32 10.10.1.31/32 10.10.1.32/32 10.10.1.33/32 10.10.1.38/32)

doc/administration/monitoring/prometheus/index.md

@@ -268,37 +268,37 @@ export Prometheus metrics.
 The node exporter allows you to measure various machine resources, such as
 memory, disk, and CPU utilization.
 
-[➔ Read more about the node exporter.](node_exporter.md)
+[Read more about the node exporter](node_exporter.md).
 
 ### Redis exporter
 
 The Redis exporter allows you to measure various Redis metrics.
 
-[➔ Read more about the Redis exporter.](redis_exporter.md)
+[Read more about the Redis exporter](redis_exporter.md).
 
-### Postgres exporter
+### PostgreSQL exporter
 
-The Postgres exporter allows you to measure various PostgreSQL metrics.
+The PostgreSQL exporter allows you to measure various PostgreSQL metrics.
 
-[➔ Read more about the Postgres exporter.](postgres_exporter.md)
+[Read more about the PostgreSQL exporter](postgres_exporter.md).
 
 ### PgBouncer exporter
 
 The PgBouncer exporter allows you to measure various PgBouncer metrics.
 
-[➔ Read more about the PgBouncer exporter.](pgbouncer_exporter.md)
+[Read more about the PgBouncer exporter](pgbouncer_exporter.md).
 
 ### Registry exporter
 
 The Registry exporter allows you to measure various Registry metrics.
 
-[➔ Read more about the Registry exporter.](registry_exporter.md)
+[Read more about the Registry exporter](registry_exporter.md).
 
 ### GitLab exporter
 
 The GitLab exporter allows you to measure various GitLab metrics, pulled from Redis and the database.
 
-[➔ Read more about the GitLab exporter.](gitlab_exporter.md)
+[Read more about the GitLab exporter](gitlab_exporter.md).
 
 ## Configuring Prometheus to monitor Kubernetes
 

doc/administration/troubleshooting/kubernetes_cheat_sheet.md

@@ -162,7 +162,7 @@ and they will assist you with any issues you are having.
   kubectl get secret <secret-name> -ojsonpath={.data.password} | base64 --decode ; echo
   ```
 
-- How to connect to a GitLab Postgres database:
+- How to connect to a GitLab PostgreSQL database:
 
   ```shell
   kubectl exec -it <task-runner-pod-name> -- /srv/gitlab/bin/rails dbconsole -p

doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md

@@ -77,6 +77,6 @@ gitlab-runner register \
   --docker-services latest
 ```
 
-With the command above, you create a Runner that uses the [ruby:2.6](https://hub.docker.com/_/ruby) image and uses a [postgres](https://hub.docker.com/_/postgres) database.
+With the command above, you create a Runner that uses the [ruby:2.6](https://hub.docker.com/_/ruby) image and uses a [PostgreSQL](https://hub.docker.com/_/postgres) database.
 
 To access the PostgreSQL database, connect to `host: postgres` as user `postgres` with no password.

doc/development/architecture.md

@@ -144,7 +144,7 @@ Component statuses are linked to configuration documentation for each component.
 | [GitLab self-monitoring: Sentry](#sentry) | Track errors generated by the GitLab instance | [⤓][sentry-omnibus] | [❌][sentry-charts] | [❌][sentry-charts] | [✅](https://about.gitlab.com/handbook/support/workflows/500_errors.html#searching-sentry) | [⤓][gitlab-yml] | [⤓][gitlab-yml] | CE & EE |
 | [GitLab self-monitoring: Jaeger](#jaeger) | View traces generated by the GitLab instance | [❌][jaeger-omnibus] | [❌][jaeger-charts] | [❌][jaeger-charts] | [❌](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4104) | [⤓][jaeger-source] | [⚙][jaeger-gdk] | CE & EE |
 | [Redis Exporter](#redis-exporter) | Prometheus endpoint with Redis metrics | [✅][redis-exporter-omnibus] | [✅][redis-exporter-charts] | [✅][redis-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
-| [Postgres Exporter](#postgres-exporter) | Prometheus endpoint with PostgreSQL metrics | [✅][postgres-exporter-omnibus] | [✅][postgres-exporter-charts] | [✅][postgres-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
+| [PostgreSQL Exporter](#postgresql-exporter) | Prometheus endpoint with PostgreSQL metrics | [✅][postgres-exporter-omnibus] | [✅][postgres-exporter-charts] | [✅][postgres-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [PgBouncer Exporter](#pgbouncer-exporter) | Prometheus endpoint with PgBouncer metrics | [⚙][pgbouncer-exporter-omnibus] | [❌][pgbouncer-exporter-charts] | [❌][pgbouncer-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [GitLab Exporter](#gitlab-exporter) | Generates a variety of GitLab metrics | [✅][gitlab-exporter-omnibus] | [✅][gitlab-exporter-charts] | [✅][gitlab-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [Node Exporter](#node-exporter) | Prometheus endpoint with system metrics | [✅][node-exporter-omnibus] | [N/A][node-exporter-charts] | [N/A][node-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
@@ -366,14 +366,14 @@ Prometheus exporter for PgBouncer. Exports metrics at 9127/metrics.
 
 GitLab packages the popular Database to provide storage for Application meta data and user information.
 
-#### Postgres Exporter
+#### PostgreSQL Exporter
 
 - [Project page](https://github.com/wrouesnel/postgres_exporter/blob/master/README.md)
 - Configuration: [Omnibus][postgres-exporter-omnibus], [Charts][postgres-exporter-charts]
 - Layer: Monitoring
 - Process: `postgres-exporter`
 
-[Postgres-exporter](https://github.com/wrouesnel/postgres_exporter) is the community provided Prometheus exporter that will deliver data about Postgres to Prometheus for use in Grafana Dashboards.
+[`postgres_exporter`](https://github.com/wrouesnel/postgres_exporter) is the community provided Prometheus exporter that will deliver data about PostgreSQL to Prometheus for use in Grafana Dashboards.
 
 #### Prometheus
 
@@ -486,7 +486,7 @@ When making a request to an HTTP Endpoint (think `/users/sign_in`) the request w
 - NGINX - Acts as our first line reverse proxy.
 - GitLab Workhorse - This determines if it needs to go to the Rails application or somewhere else to reduce load on Unicorn.
 - Unicorn - Since this is a web request, and it needs to access the application it will go to Unicorn.
-- Postgres/Gitaly/Redis - Depending on the type of request, it may hit these services to store or retrieve data.
+- PostgreSQL/Gitaly/Redis - Depending on the type of request, it may hit these services to store or retrieve data.
 
 ### GitLab Git Request Cycle
 

doc/development/diffs.md

@@ -26,7 +26,7 @@ The diffs fetching process _limits_ single file diff sizes and the overall size
 then persisted on `merge_request_diff_files` table.
 
 Even though diffs larger than 10% of the value of `ApplicationSettings#diff_max_patch_bytes` are collapsed,
-we still keep them on Postgres. However, diff files larger than defined _safety limits_
+we still keep them on PostgreSQL. However, diff files larger than defined _safety limits_
 (see the [Diff limits section](#diff-limits)) are _not_ persisted in the database.
 
 In order to present diffs information on the Merge Request diffs page, we:

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 [Postgres's arrays](https://www.postgresql.org/docs/9.6/arrays.html) became more
+using [PostgreSQL's arrays](https://www.postgresql.org/docs/9.6/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),

doc/development/merge_request_performance_guidelines.md

@@ -205,7 +205,7 @@ Using [`ReactiveCaching`](utilities.md#reactivecaching) is one of the best solut
 
 **Summary:** You should avoid accessing to external services like Gitaly during database
 transactions, otherwise it leads to severe contention problems
-as an open transaction basically blocks the release of a Postgres backend connection.
+as an open transaction basically blocks the release of a PostgreSQL backend connection.
 
 For keeping transaction as minimal as possible, please consider using `AfterCommitQueue`
 module or `after_commit` AR hook.

doc/development/sidekiq_style_guide.md

@@ -181,7 +181,7 @@ execution latency requirements (but also has lower scheduling targets).
 ## Jobs with External Dependencies
 
 Most background jobs in the GitLab application communicate with other GitLab
-services. For example, Postgres, Redis, Gitaly, and Object Storage. These are considered
+services. For example, PostgreSQL, Redis, Gitaly, and Object Storage. These are considered
 to be "internal" dependencies for a job.
 
 However, some jobs will be dependent on external services in order to complete
@@ -224,7 +224,7 @@ Workers that are constrained by CPU or memory resource limitations should be
 annotated with the `worker_resource_boundary` method.
 
 Most workers tend to spend most of their time blocked, wait on network responses
-from other services such as Redis, Postgres and Gitaly. Since Sidekiq is a
+from other services such as Redis, PostgreSQL, and Gitaly. Since Sidekiq is a
 multithreaded environment, these jobs can be scheduled with high concurrency.
 
 Some workers, however, spend large amounts of time _on-CPU_ running logic in

doc/development/understanding_explain_plans.md

@@ -651,8 +651,8 @@ different queries. The only _rule_ is that you _must always measure_ your query
 (preferably using a production-like database) using `EXPLAIN (ANALYZE, BUFFERS)`
 and related tools such as:
 
-- <https://explain.depesz.com/>
-- <http://tatiyants.com/postgres-query-plan-visualization/>
+- [`explain.depesz.com`](https://explain.depesz.com/).
+- [Pev](http://tatiyants.com/postgres-query-plan-visualization/).
 
 ## Producing query plans
 
@@ -707,7 +707,13 @@ For more information about the available options, run:
 
 ### `#database-lab`
 
-Another tool GitLab employees can use is a chatbot powered by [Joe](https://gitlab.com/postgres-ai/joe) which uses [Database Lab](https://gitlab.com/postgres-ai/database-lab) to instantly provide developers with their own clone of the production database. Joe is available in the [`#database-lab`](https://gitlab.slack.com/archives/CLJMDRD8C) channel on Slack.
+Another tool GitLab employees can use is a chatbot powered by [Joe](https://gitlab.com/postgres-ai/joe)
+which uses [Database Lab](https://gitlab.com/postgres-ai/database-lab) to instantly provide developers
+with their own clone of the production database.
+
+Joe is available in the
+[`#database-lab`](https://gitlab.slack.com/archives/CLJMDRD8C) channel on Slack.
+
 Unlike chatops, it gives you a way to execute DDL statements (like creating indexes and tables) and get query plan not only for `SELECT` but also `UPDATE` and `DELETE`.
 
 For example, in order to test new index you can do the following:

doc/install/aws/index.md

@@ -487,7 +487,7 @@ gitlab=# \q
 
 ---
 
-### Configuring GitLab to connect with postgres and Redis
+### Configuring GitLab to connect with PostgreSQL and Redis
 
 Edit the `gitlab.rb` file at `/etc/gitlab/gitlab.rb`
 find the `external_url 'http://gitlab.example.com'` option and change it

doc/integration/elasticsearch.md

@@ -632,5 +632,5 @@ Sometimes there may be issues with your Elasticsearch index data and as such
 GitLab will allow you to revert to "basic search" when there are no search
 results and assuming that basic search is supported in that scope. This "basic
 search" will behave as though you don't have Elasticsearch enabled at all for
-your instance and search using other data sources (ie. Postgres data and Git
+your instance and search using other data sources (ie. PostgreSQL data and Git
 data).

doc/raketasks/backup_restore.md

@@ -850,7 +850,7 @@ Example: Amazon EBS
 > A GitLab server using Omnibus GitLab hosted on Amazon AWS.
 > An EBS drive containing an ext4 filesystem is mounted at `/var/opt/gitlab`.
 > In this case you could make an application backup by taking an EBS snapshot.
-> The backup includes all repositories, uploads and Postgres data.
+> The backup includes all repositories, uploads and PostgreSQL data.
 
 Example: LVM snapshots + rsync
 
@@ -858,7 +858,7 @@ Example: LVM snapshots + rsync
 > Replicating the `/var/opt/gitlab` directory using rsync would not be reliable because too many files would change while rsync is running.
 > Instead of rsync-ing `/var/opt/gitlab`, we create a temporary LVM snapshot, which we mount as a read-only filesystem at `/mnt/gitlab_backup`.
 > Now we can have a longer running rsync job which will create a consistent replica on the remote server.
-> The replica includes all repositories, uploads and Postgres data.
+> The replica includes all repositories, uploads and PostgreSQL data.
 
 If you are running GitLab on a virtualized server you can possibly also create VM snapshots of the entire GitLab server.
 It is not uncommon however for a VM snapshot to require you to power down the server, so this approach is probably of limited practical use.

doc/topics/autodevops/upgrading_postgresql.md

@@ -212,7 +212,7 @@ specific environments, e.g. `staging`.
 1. Once connected to the pod, run the following command to restore the database.
 
    - You will be asked for the database password, the default is `testing-password`.
-   - `USERNAME` is the username you have configured for postgres. The default is `user`.
+   - `USERNAME` is the username you have configured for PostgreSQL. The default is `user`.
    - `DATABASE_NAME` is usually the environment name.
 
    ```sh

doc/user/application_security/container_scanning/index.md

@@ -176,12 +176,12 @@ using environment variables.
 | `CLAIR_OUTPUT`                 | Severity level threshold. Vulnerabilities with severity level higher than or equal to this threshold will be outputted. Supported levels are `Unknown`, `Negligible`, `Low`, `Medium`, `High`, `Critical` and `Defcon1`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           | `Unknown`                                                                                                       |
 | `REGISTRY_INSECURE`            | Allow [Klar](https://github.com/optiopay/klar) to access insecure registries (HTTP only). Should only be set to `true` when testing the image locally.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             | `"false"`                                                                                                       |
 | `DOCKER_INSECURE`              | Allow [Klar](https://github.com/optiopay/klar) to access secure Docker registries using HTTPS with bad (or self-signed) SSL certificates.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          | `"false"`                                                                                                       |
-| `CLAIR_VULNERABILITIES_DB_URL` | (**DEPRECATED - use `CLAIR_DB_CONNECTION_STRING` instead**) This variable is explicitly set in the [services section](https://gitlab.com/gitlab-org/gitlab/-/blob/898c5da43504eba87b749625da50098d345b60d6/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L23) of the `Container-Scanning.gitlab-ci.yml` file and defaults to `clair-vulnerabilities-db`. This value represents the address that the [Postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) is running on and **shouldn't be changed** unless you're running the image locally as described in the [Running the standalone Container Scanning Tool](#running-the-standalone-container-scanning-tool) section.                                      | `clair-vulnerabilities-db`                                                                                      |
-| `CLAIR_DB_CONNECTION_STRING`   | This variable represents the [connection string](https://www.postgresql.org/docs/9.3/libpq-connect.html#AEN39692) to the [Postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) database and **shouldn't be changed** unless you're running the image locally as described in the [Running the standalone Container Scanning Tool](#running-the-standalone-container-scanning-tool) section. The host value for the connection string must match the [alias](https://gitlab.com/gitlab-org/gitlab/-/blob/898c5da43504eba87b749625da50098d345b60d6/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L23) value of the `Container-Scanning.gitlab-ci.yml` template file, which defaults to `clair-vulnerabilities-db`. | `postgresql://postgres:password@clair-vulnerabilities-db:5432/postgres?sslmode=disable&statement_timeout=60000` |
+| `CLAIR_VULNERABILITIES_DB_URL` | (**DEPRECATED - use `CLAIR_DB_CONNECTION_STRING` instead**) This variable is explicitly set in the [services section](https://gitlab.com/gitlab-org/gitlab/-/blob/898c5da43504eba87b749625da50098d345b60d6/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L23) of the `Container-Scanning.gitlab-ci.yml` file and defaults to `clair-vulnerabilities-db`. This value represents the address that the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) is running on and **shouldn't be changed** unless you're running the image locally as described in the [Running the standalone Container Scanning Tool](#running-the-standalone-container-scanning-tool) section.                                      | `clair-vulnerabilities-db`                                                                                      |
+| `CLAIR_DB_CONNECTION_STRING`   | This variable represents the [connection string](https://www.postgresql.org/docs/9.3/libpq-connect.html#AEN39692) to the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) database and **shouldn't be changed** unless you're running the image locally as described in the [Running the standalone Container Scanning Tool](#running-the-standalone-container-scanning-tool) section. The host value for the connection string must match the [alias](https://gitlab.com/gitlab-org/gitlab/-/blob/898c5da43504eba87b749625da50098d345b60d6/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L23) value of the `Container-Scanning.gitlab-ci.yml` template file, which defaults to `clair-vulnerabilities-db`. | `postgresql://postgres:password@clair-vulnerabilities-db:5432/postgres?sslmode=disable&statement_timeout=60000` |
 | `CI_APPLICATION_REPOSITORY`    | Docker repository URL for the image to be scanned.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 | `$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG`                                                                        |
 | `CI_APPLICATION_TAG`           | Docker respository tag for the image to be scanned.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | `$CI_COMMIT_SHA`                                                                                                |
-| `CLAIR_DB_IMAGE`               | The Docker image name and tag for the [Postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes, or to refer to a locally hosted vulnerabilities database for an on-premise air-gapped installation.                                                                                                                                                                                                                                                                                                                                                                      | `arminc/clair-db:latest`                                                                                        |
-| `CLAIR_DB_IMAGE_TAG`           | (**DEPRECATED - use `CLAIR_DB_IMAGE` instead**) The Docker image tag for the [Postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes.                                                                                                                                                                                                                                                                                                                                                                                                                                   | `latest`                                                                                                        |
+| `CLAIR_DB_IMAGE`               | The Docker image name and tag for the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes, or to refer to a locally hosted vulnerabilities database for an on-premise air-gapped installation.                                                                                                                                                                                                                                                                                                                                                                      | `arminc/clair-db:latest`                                                                                        |
+| `CLAIR_DB_IMAGE_TAG`           | (**DEPRECATED - use `CLAIR_DB_IMAGE` instead**) The Docker image tag for the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes.                                                                                                                                                                                                                                                                                                                                                                                                                                   | `latest`                                                                                                        |
 | `DOCKERFILE_PATH`              | The path to the `Dockerfile` to be used for generating remediations. By default, the scanner will look for a file named `Dockerfile` in the root directory of the project, so this variable should only be configured if your `Dockerfile` is in a non-standard location, such as a subdirectory. See [Solutions for vulnerabilities](#solutions-for-vulnerabilities-auto-remediation) for more details.                                                                                                                                                                                                                                                                                                                                                                          | `Dockerfile`                                                                                                    |
 | `ADDITIONAL_CA_CERT_BUNDLE`   | Bundle of CA certs that you want to trust. | "" |
 

doc/user/clusters/crossplane.md

@@ -143,9 +143,9 @@ kubectl describe globaladdress.compute.gcp.crossplane.io gitlab-ad-globaladdress
 
 ## Setting up Resource classes
 
-Resource classes are a way of defining a configuration for the required managed service. We will define the Postgres Resource class
+Resource classes are a way of defining a configuration for the required managed service. We will define the PostgreSQL Resource class
 
-- Define a gcp-postgres-standard.yaml resourceclass which contains
+- Define a `gcp-postgres-standard.yaml` resourceclass which contains
 
 1. A default CloudSQLInstanceClass.
 1. A CloudSQLInstanceClass with labels.
@@ -285,4 +285,4 @@ serverCACertificateSha1Fingerprint:   40 bytes
 ## Connect to the PostgreSQL instance
 
 Follow this [GCP guide](https://cloud.google.com/sql/docs/postgres/connect-kubernetes-engine) if you
-would like to connect to the newly provisioned Postgres database instance on CloudSQL.
+would like to connect to the newly provisioned PostgreSQL database instance on CloudSQL.

doc/user/project/clusters/add_remove_clusters.md

@@ -660,14 +660,14 @@ kubectl create clusterrolebinding permissive-binding \
 
 Amazon EKS doesn't have a default Storage Class out of the box, which means
 requests for persistent volumes will not be automatically fulfilled. As part
-of Auto DevOps, the deployed Postgres instance requests persistent storage,
+of Auto DevOps, the deployed PostgreSQL instance requests persistent storage,
 and without a default storage class it will fail to start.
 
 If a default Storage Class doesn't already exist and is desired, follow Amazon's
 [guide on storage classes](https://docs.aws.amazon.com/eks/latest/userguide/storage-classes.html)
 to create one.
 
-Alternatively, disable Postgres by setting the project variable
+Alternatively, disable PostgreSQL by setting the project variable
 [`POSTGRES_ENABLED`](../../../topics/autodevops/#environment-variables) to `false`.
 
 #### Deploy the app to EKS

doc/user/project/clusters/runbooks/index.md

@@ -120,7 +120,7 @@ VARIABLE_VALUE = project.variables.get('PRIVATE_TOKEN').value
 ### 5. Configure an operation
 
 For this example we'll use the "**Run SQL queries in Notebook**" section in the sample runbook to query
-a postgres database. The first 4 lines of the section define the variables that are required for this query to function.
+a PostgreSQL database. The first 4 lines of the section define the variables that are required for this query to function.
 
 ```sql
 %env DB_USER={project.variables.get('DB_USER').value}
@@ -136,7 +136,7 @@ Create the matching variables in your project's **Settings >> CI/CD >> Variables
 Back in Jupyter, click the "Run SQL queries in Notebook" heading and the click *Run*. The results will be
 displayed in-line as follows:
 
-![postgres query](img/postgres-query.png)
+![PostgreSQL query](img/postgres-query.png)
 
 You can try other operations such as running shell scripts or interacting with a Kubernetes cluster. Visit the
 [Nurtch Documentation](http://docs.nurtch.com/) for more information.