Merge pull request #3087 from EnterpriseDB/release/2022-08-25

Release: 2022-08-25
EnterpriseDB · Aug 25, 2022 · f2bcfc4 · f2bcfc4
2 parents a608bd7 + 29cabb3
commit f2bcfc4
Show file tree

Hide file tree

Showing 6 changed files with 30 additions and 12 deletions.
diff --git a/product_docs/docs/biganimal/release/free_trial/detail/create_an_account/index.mdx b/product_docs/docs/biganimal/release/free_trial/detail/create_an_account/index.mdx
@@ -4,17 +4,18 @@ description: "Creating an EDB account and signing into the BigAnimal free trial
 navTitle: "Create an account" 
 ---
 
-Registering an account on [enterprisedb.com](https://www.enterprisedb.com/) gets you access to the BigAnimal trial, as well as EDB's training and software downloads. 
+You need to register with EDB to access the BigAnimal free trial and EDB's training and software downloads.
+
 Accounts are free, and registration takes less than a minute.
 
 1. Navigate to <https://biganimal.com>.
-2. Select the **Try it for free** button.
-3. Fill in the form, and agree to the terms and conditions.
+2. Select the **Test drive for free** button.
+3. Fill in the form, and agree to the terms and conditions and privacy policy.
 4. Select **Submit**.
-5. Check your email. You should receive an email from EDB containing an activation link.
+5. Check your email for an email from EDB that contains an activation link.
 6. Select the activation link and enter a password for your EDB account.
 
 You're then redirected to the BigAnimal portal.
 
 !!! Note "Already have an EDB account?"
-    If you've already signed up for an EDB account, you can navigate to <https://portal.biganimal.com/> to log in.
+    If you already signed up for an EDB account, navigate to https://freetrial.biganimal.com/ to log in. Continue to use this portal to access BigAnimal for the rest of your free trial.
diff --git a/.../preparing_cloud_account/01_preparing_azure/01_understanding_qotas_in_azure.mdx b/.../preparing_cloud_account/01_preparing_azure/01_understanding_qotas_in_azure.mdx
@@ -67,4 +67,4 @@ BigAnimal recommends the following per region when requesting virtual machine re
 
 -   Total Regional vCPUs: minimum of 60 per designated region
 -   Standard ESv3 Family vCPUs: minimum of 50 per designated region
--   Standard Dv4 Family vCPUs: minimum of 10 per designated region
+-   Standard Dv4 Family vCPUs: minimum of 14 per designated region
diff --git a/...s/migration_portal/4/04_mp_migrating_database/01_mp_schema_extraction/index.mdx b/...s/migration_portal/4/04_mp_migrating_database/01_mp_schema_extraction/index.mdx
@@ -84,7 +84,7 @@ Extract dependent object from other schemas?(yes/no) (Default no / Ignored for a
 
 After loading the `edb_ddl_extractor.sql` script into SQL Developer and connecting to the source Oracle database, run the script. As the script executes, respond to the prompts.
 
-1.  If the the user for the database connection has the required privileges as listed in the **Script Output** tab, select **Yes** to continue running the script.
+1.  If the user for the database connection has the required privileges as listed in the **Script Output** tab, select **Yes** to continue running the script.
 
 2.  Enter a comma-separated list of schemas and select **OK**.
 

diff --git a/product_docs/docs/pem/8/pem_upgrade/upgrading_backend_database.mdx b/product_docs/docs/pem/8/pem_upgrade/upgrading_backend_database.mdx
@@ -10,13 +10,28 @@ redirects:
 If you're updating PEM components and the PEM backend database, perform PEM component updates on the server and agent before updating the backend database. For more information about updating PEM component software, see [Upgrading a PEM installation](upgrading_pem_installation/).
 
 !!! Note
-    From PEM version 8.0 and later, the PostgreSQL or EDB Postgres version 11 or later are supported only as a backend database server. If your backend database server is earlier than version 11, then first you need to upgrade your backend database server. Then upgrade the PEM components.
+    -   From PEM 8.0 onwards, PostgreSQL or EPAS versions 11 or later are only supported as backend database servers. As a result, if 
+        your backend database server is earlier than version 11, you need to first upgrade your backend database server and then upgrade the PEM components.
+
+    -   After upgrading the backend database server, if you encounter this error while creating the server in the PEM web interface:
+
+        ```text
+        Error - User does not have enough permission to add new server.
+                Please contact the administrator to grant 'pem_database_server_registration' role 
+                to the 'enterprisedb' user.
+        ```
+
+        Resolve the error by updating the roles and granting appropriate permissions:
+
+       ```sql
+       UPDATE pem.roles SET rolid = pr.oid FROM pg_roles pr WHERE pr.rolname = 'pem_' || component;
+       ```
 
 The update process uses the pg_upgrade utility to migrate from one version of the backend server to a more recent version. pg_upgrade enables migration between any supported version of Postgres and any subsequent release of Postgres that's supported on the same platform.
 
 If the source PEM server is earlier than the 7.16 version, then you need to replace the following functions before you run pg_upgrade:
 
-    -   The `abstime`, `reltime`, and `tinterval` datatypes are deprecated from Postgres version 12 or later, hence to replace those dataypes  with `timestamptz` data type use this command:
+-  The `abstime`, `reltime`, and `tinterval` datatypes are deprecated from Postgres version 12 or later, hence to replace those dataypes  with `timestamptz` data type use this command:
 
     ```sql
     DO
@@ -35,7 +50,7 @@ If the source PEM server is earlier than the 7.16 version, then you need to repl
         ALTER TABLE pemdata.user_info
             ALTER COLUMN valuntil SET DATA TYPE timestamptz;
         ALTER TABLE pemhistory.user_info
-            ALTER COLUMN valuntil SET DATA TYPE timestamptz;
+                ALTER COLUMN valuntil SET DATA TYPE timestamptz;
         -- Now update the pem.probe_column itself
         UPDATE pem.probe_column
         SET sql_data_type = ‘timestamptz’

diff --git a/product_docs/docs/pgd/4/overview/bdr/catalogs.mdx b/product_docs/docs/pgd/4/overview/bdr/catalogs.mdx
@@ -24,7 +24,7 @@ For details, see [Logging conflicts to a table](conflicts).
 | ----------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------ |
 | sub_id                  | oid                      | Which subscription produced this conflict; can be joined to `bdr.subscription` table                                     |
 | local_xid               | xid                      | Local transaction of the replication process at the time of conflict                                                     |
-| local_lsn               | pg_lsn                   | Local transaction of the replication process at the time of conflict                                                     |
+| local_lsn               | pg_lsn                   | Local LSN at the time of conflict                                                     |
 | local_time              | timestamp with time zone | Local time of the conflict                                                                                               |
 | remote_xid              | xid                      | Transaction that produced the conflicting change on the remote node (an origin)                                         |
 | remote_commit_lsn       | pg_lsn                   | Commit LSN of the transaction which produced the conflicting change on the remote node (an origin)                      |
@@ -1292,6 +1292,8 @@ An internal catalog table holding state per DDL epoch.
 | origin_node_id        | oid         | Internal node ID of the node that requested creation of this epoch       |
 | epoch_consume_timeout | timestamptz | Timeout of this epoch                                                    |
 | epoch_consumed        | boolean     | Switches to true as soon as the local node has fully processed the epoch |
+| epoch_consumed_lsn    | boolean     | LSN at which the local node has processed the epoch                      |
+
 
 ### `bdr.internal_node_pre_commit`
 

diff --git a/product_docs/docs/pgd/4/overview/harp/02_overview.mdx b/product_docs/docs/pgd/4/overview/harp/02_overview.mdx
@@ -33,7 +33,7 @@ target is ambiguous or unknowable. In a standard Postgres cluster, it's
 important that only a single node is ever writable and sending replication
 traffic to the remaining nodes.
 
-Even in multi-master-capable approaches such as BDR, it can be help to
+Even in multi-master-capable approaches such as BDR, it can be helpful to
 reduce the amount of necessary conflict management to derive identical data
 across the cluster. In clusters that consist of multiple BDR nodes per physical
 location or region, this usually means a single BDR node acts as a "leader" and