Merge pull request #4025 from EnterpriseDB/release/2023-05-04

Release: 2023-05-04

product_docs/docs/biganimal/release/getting_started/creating_a_cluster/creating_an_eha_cluster.mdx

@@ -15,6 +15,8 @@ When you create an extreme-high-availability cluster, you need to set up the dat
    1.  Select the type of Postgres you want to use in the **Postgres Type** field:
 
         -   **Oracle Compatible** is powered by [EDB Postgres Advanced Server](/epas/latest/). View [a quick demonstration of Oracle compatibility on BigAnimal](../../using_cluster/06_demonstration_oracle_compatibility). EDB Postgres Advanced Server is compatible with all three cluster types.
+
+        - **PostgreSQL Compatible** is powered by [EDB Postgres Extended Server](/pge/latest/), which uses advanced logical replication of data and schema. EDB Postgres Extended server is compatible only with extreme-high-availability clusters. 
 
     1.  In the **Postgres Version** list, select either 14 or 15 as the version of Postgres that you want to use. 
 

product_docs/docs/biganimal/release/knowledge_base.mdx

@@ -8,7 +8,7 @@ The BigAnimal Support team provides a [knowledge base](https://support.biganimal
 Follow the knowledge base to be notified of new articles. 
 
 
-## Stepping up specific identity provider articles
+## Setting up specific identity provider articles
 
 See the following articles for step-by-step instructions for setting up specific identity providers:
 

product_docs/docs/biganimal/release/overview/02_high_availability.mdx

@@ -18,6 +18,7 @@ Postgres distribution and version support varies by cluster type.
 | PostgreSQL            | 11–15            | Single node, high availability |
 | Oracle Compatible     | 11–15            | Single node, high availability |
 | Oracle Compatible     | 14–15            | Extreme high availability      |
+| PostgreSQL Compatible | 14-15            | Extreme high availability      | 
 
 ## Single node
 
@@ -57,11 +58,11 @@ Since BigAnimal replicates to only one node synchronously, some standby replicas
 
 For use cases where high availability across regions is a major concern, a cluster deployment with extreme high availability enabled can provide two data group with three data nodes each, plus a witness group, for a true active-active solution. Extreme-high-availability clusters offer the ability to deploy a cluster across multiple regions or a single region. Extreme-high-availability clusters are powered by [EDB Postgres Distributed](/pgd/latest/) using multi-master logical replication.
 
-Extreme-high-availability clusters are only Oracle compatible. 
+Extreme-high-availability clusters are Oracle compatible and PostgreSQL compatible. 
 
 Extreme-high-availability clusters are configured according to *data groups*. EDB Postgres Distributed (PGD) clusters create a PGD global group, which contains one or two data groups. Your data groups can be made up of a combination of data nodes and witness nodes. One of these data nodes is the leader at any given time, while the rest are shadow nodes. 
 
-PGD Proxy routes all application traffic to the leader node, which acts as the principal write target to reduce the potential for data conflicts. PGD Proxy leverages a distributed consensus model to determine availability of the data nodes in the cluster. On failure or unavailability of the leader, PGD Proxy elects a new leader and redirects application traffic. Together with the core capabilities of EDB Postgres Distributed, this mechanism of routing application traffic to the leader node enables fast failover and switchover.
+[PGD Proxy](/pgd/latest/routing/proxy) routes all application traffic to the leader node, which acts as the principal write target to reduce the potential for data conflicts. PGD Proxy leverages a distributed consensus model to determine availability of the data nodes in the cluster. On failure or unavailability of the leader, PGD Proxy elects a new leader and redirects application traffic. Together with the core capabilities of EDB Postgres Distributed, this mechanism of routing application traffic to the leader node enables fast failover and switchover.
 
 The witness node/witness group doesn't host data but exists for management purposes, supporting operations that require a consensus, for example, in case of an availability zone failure. 
 

product_docs/docs/biganimal/release/overview/05_database_version_policy.mdx

@@ -10,7 +10,7 @@ We support the major Postgres versions from the date they're made available unti
 | ---------------------------- | --------------------------------------------------- |
 | PostgreSQL                   | 11–15                                               |
 | EDB Postgres Advanced Server | 11–15, 14-15 for extreme-high-availability clusters |
-| EDB Postgres Extended Server | 12-15                                               |
+| EDB Postgres Extended Server | 14-15 for extreme-high-availability clusters |
 
 ## End-of-life policy
 

product_docs/docs/biganimal/release/using_cluster/01_postgres_access.mdx

@@ -2,51 +2,51 @@
 title: "Managing Postgres access"
 ---
 
-You control access to your Postgres database by database authentication implemented by creating databases with specific roles and privileges. Database authentication differs from portal authentication, which controls access to the BigAnimal portal. 
+You control access to your Postgres database using database authentication implemented by creating databases with specific roles and privileges. Database authentication differs from portal authentication, which controls access to the BigAnimal portal. 
 
 For information on portal authentication, see:
 
-- [Setting up your identity provider](/biganimal/latest/getting_started/identity_provider/) if you purchased BigAnimal directly from EDB, or
+- [Setting up your identity provider](/biganimal/latest/getting_started/identity_provider/) if you purchased BigAnimal directly from EDB
 - [Setting up your Azure Marketplace account](/biganimal/latest/getting_started/02_azure_market_setup/) if you purchased BigAnimal through Azure Marketplace
 
 ## Setting up your database authentication
-Don't use the `edb_admin` database role and `edb_admin` database created when creating your cluster in your application. Instead, create a new database role and a new database, which provides a high level of isolation in Postgres. If multiple applications are using the same cluster, each database can also contain multiple schemas, essentially a namespace in the database. If strict isolation is needed, use a dedicated cluster or dedicated database. If that strict isolation level isn't required, you can deploy a single database with multiple schemas. Refer to [Privileges](https://www.postgresql.org/docs/current/ddl-priv.html) in the PostgreSQL documentation to further customize ownership and roles to your requirements.
+Don't use the edb_admin database role and edb_admin database created when creating your cluster in your application. Instead, create a new database role and a new database, which provides a high level of isolation in Postgres. If multiple applications are using the same cluster, each database can also contain multiple schemas, essentially a namespace in the database. If you need strict isolation, use a dedicated cluster or dedicated database. If you don't need that strict isolation level, you can deploy a single database with multiple schemas. See [Privileges](https://www.postgresql.org/docs/current/ddl-priv.html) in the PostgreSQL documentation to further customize ownership and roles to your requirements.
 
 To create a new role and database, first connect using `psql`:
 
 ```shell
 psql -W "postgres://[email protected]:5432/edb_admin?sslmode=require"
 ```
 !!! Note
-    Avoid storing data in the `postgres` system database.
+    Avoid storing data in the postgres system database.
 
 ## Notes on the edb_admin role
 
-- The `edb_admin` role does not have superuser privileges by default. Contact [Support](../overview/support) to request superuser privileges for `edb_admin`. If you request superuser privileges, you **must** take care to limit the number of connections used by superusers to avoid degraded service and/or compromising availability.
+- The edb_admin role doesn't have superuser privileges by default. Contact [Support](../overview/support) to request superuser privileges for edb_admin. If you request superuser privileges, you must take care to limit the number of connections used by superusers to avoid degraded service or compromising availability.
 
   !!! note
-      Superuser privileges allow you to make Postgres configuration changes using `ALTER SYSTEM` queries. We recommend you don't do this because it may lead to an unpredictable/unrecoverable state of the cluster. In addition, `ALTER SYSTEM` changes are not replicated across the cluster.
+      Superuser privileges allow you to make Postgres configuration changes using `ALTER SYSTEM` queries. We recommend you don't do this because it might lead to an unpredictable or unrecoverable state of the cluster. In addition, `ALTER SYSTEM` changes aren't replicated across the cluster.
 
-- Changes to system configuration (GUCs) made by edb_admin or other Postgres users are not persisted though a reboot or maintenance. Use the BigAnimal portal to modify system configuration.
+- Changes to system configuration (GUCs) made by edb_admin or other Postgres users don't persist through a reboot or maintenance. Use the BigAnimal portal to modify system configuration.
 
--   You have to remember your `edb_admin` password as EDB does not have access to it. If you forget it, you can set a new one in the BigAnimal portal on the Edit Cluster page.
+-   You have to remember your edb_admin password, as EDB doesn't have access to it. If you forget it, you can set a new one in the BigAnimal portal on the Edit Cluster page.
 
--   Don't use the `edb_admin` user or the `edb_admin` database in your applications. Instead, use `CREATE USER; GRANT; CREATE DATABASE.`
+-   Don't use the edb_admin user or the edb_admin database in your applications. Instead, use `CREATE USER; GRANT; CREATE DATABASE.`
 
--   BigAnimal stores all database-level authentication securely and directly in PostgreSQL. The `edb_admin` user password is SCRAM-SHA-256 hashed prior to storage. This hash, even if compromised, cannot be replayed by an attacker to gain access to the system.
+-   BigAnimal stores all database-level authentication securely and directly in PostgreSQL. The `edb_admin` user password is `SCRAM-SHA-256` hashed prior to storage. This hash, even if compromised, can't be replayed by an attacker to gain access to the system.
 
 
 
 ## One database with one application
 
-For one database hosting a single application, replace app1 with your preferred user name:
+For one database hosting a single application, replace `app1` with your preferred user name:
 
 1.  Create a new database user. For example,
     ```
     edb_admin=# create user app1 with password 'app1_pwd';
     ```
 
-2.  Assign the new role to your `edb_admin` user. Assigning this role allows you to assign ownership to the new user in the next step. For example:
+2.  Assign the new role to your edb_admin user. Assigning this role allows you to assign ownership to the new user in the next step. For example:
     ```
     edb_admin=# grant app1 to edb_admin;
     ```
@@ -56,11 +56,11 @@ For one database hosting a single application, replace app1 with your preferred
     edb_admin=# create database app1 with owner app1;
     ```
 
-Using this example, the username and database in your connection string is `app1`.
+Using this example, the username and database in your connection string is app1.
 
 ## One database with multiple schemas
 
-If a single database is used to host multiple schemas, create a database owner and then roles and schemas for each application. This example shows creating two database roles and two schemas. The default `search_path` for database roles in BigAnimal is `"$user",public`. If the role name and schema match, then objects in that schema match first, and no `search_path` changes or fully qualifying of objects are needed. The [PostgreSQL documentation](https://www.postgresql.org/docs/current/ddl-schemas.html#DDL-SCHEMAS-PATH) covers the schema search path in detail.
+If you use a single database to host multiple schemas, create a database owner and then roles and schemas for each application. This example shows creating two database roles and two schemas. The default `search_path` for database roles in BigAnimal is `"$user",public`. If the role name and schema match, then objects in that schema match first, and no `search_path` changes or fully qualifying of objects are needed. The [PostgreSQL documentation](https://www.postgresql.org/docs/current/ddl-schemas.html#DDL-SCHEMAS-PATH) covers the schema search path in detail.
 
 1.  Create a database owner and new database. For example:
     ```
@@ -83,14 +83,14 @@ If a single database is used to host multiple schemas, create a database owner a
     prod1=# grant app2 to edb_admin;
     ```
 
-4.  Create a new schema for each application with the AUTHORIZATION clause for the application owner. For example:
+4.  Create a new schema for each application with the `AUTHORIZATION` clause for the application owner. For example:
     ```
     prod1=# create schema app1 authorization app1;
     prod1=# create schema app2 authorization app2;
     ```
 ## IAM authentication for Postgres
 
-Any AWS user with an AWS account connected to a BigAnimal subscription who has the Postgres role of "iam_aws" can authenticate to the database using their AWS IAM credentials.
+Any AWS user with an AWS account connected to a BigAnimal subscription who has the Postgres role of iam_aws can authenticate to the database using their AWS IAM credentials.
 
 ### Configuring IAM for Postgres
 
@@ -100,7 +100,7 @@ Provision your cluster before configuring IAM for Postgres.
     1. On the **Additional Settings** tab, under **Authentication**, select **Identity and Access Management (IAM) Authentication**. 
     1. Select **Create Cluster** or **Save**.
     !!!note
-    To turn on IAM authentication using the CLI, see the [Using IAM authentication on AWS](/biganimal/latest/reference/cli/using_features/#iam-authentication-cli-commands) section in the Using the BigAnimal CLI topic.
+    To turn on IAM authentication using the CLI, see [Using IAM authentication on AWS](/biganimal/latest/reference/cli/using_features/#iam-authentication-cli-commands).
 1. In AWS, get the ARN of each IAM user requiring database access. In the AWS account connected to BigAnimal, use AWS Identity and Access Management (IAM) to perform user management. See the [AWS documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html). 
 
 1. In Postgres, if the IAM role doesn’t exist yet, run this Postgres command:
@@ -124,7 +124,7 @@ If IAM integration is configured for your cluster, you can log in to Postgres us
 
 1. Using your AWS CLI or Cloud shell, obtain your ARN and access key. For guidance on obtaining your ARN and access key, see [Managing access keys for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html).
 1. Connect to Postgres using your IAM credentials.
-1. When prompted for the password, enter your access key (<access key ID>:<secret access key>).
+1. When prompted for the password, enter your access key (`<access key ID><secret access key>`).
 
 ### Using IAM authentication CLI commands
 

product_docs/docs/biganimal/release/using_cluster/03_modifying_your_cluster/index.mdx

@@ -21,7 +21,7 @@ You can also modify your cluster by installing Postgres extensions. See [Postgre
 4. You can modify the following settings on the corresponding tab of the Edit Cluster page.
 
    !!! Note
-       Any changes made to the cluster's instance type, volume type, or volume properties aren't automatically applied to its replicas' settings. To avoid lag during replication, ensure that your replicas' instance and storage types are at least as large as the source cluster's instance and storage types. See [Modify a faraway replica](/biganimal/latest/using_cluster/managing_replicas/#modify-a-faraway-replica).
+       Any changes made to the cluster's instance type, volume type, or volume properties aren't automatically applied to replica settings. To avoid lag during replication, ensure that replica instance and storage types are at least as large as the source cluster's instance and storage types. See [Modify a faraway replica](/biganimal/latest/using_cluster/managing_replicas/#modify-a-faraway-replica).
 
    |                       Settings                       |         Tab         |                                                                                                                                                                                Notes                                                                                                                                                                                 |
    | ---------------------------------------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |