Merge pull request #1072 from EnterpriseDB/content/pem/8.0.1/format-f…

…ix-for-upgrade-guide Formatting for a note is fixed in PEM Upgrade guide Former-commit-id: e42a637
EnterpriseDB · Mar 16, 2021 · 942608a · 942608a
2 parents c441e83 + f808ece
commit 942608a
Show file tree

Hide file tree

Showing 4 changed files with 67 additions and 70 deletions.
diff --git a/product_docs/docs/pem/8.0.1/pem_upgrade/02_upgrading_backend_database.mdx b/product_docs/docs/pem/8.0.1/pem_upgrade/02_upgrading_backend_database.mdx
@@ -12,57 +12,56 @@ The update process described in this section uses the `pg_upgrade` utility to mi
 !!! Note
     If the source PEM Server is lower 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 depreacated from Postgres version 12 or later, hence to replace those dataypes  with `timestamptz` data type use below command:
-
-```text
-DO
-$$
-DECLARE
-    rec record;
-    cnt integer;
-BEGIN
-    -- Check for the deprecated type in our user info probe
-    SELECT count(*) INTO cnt
-    FROM pem.probe_column
-    WHERE sql_data_type = ‘abstime’ AND internal_name = ‘valuntil’;
-        IF cnt = 0 THEN
-            RETURN;
-        END IF;
-    ALTER TABLE pemdata.user_info
-        ALTER COLUMN valuntil SET DATA TYPE timestamptz;
-    ALTER TABLE pemhistory.user_info
-        ALTER COLUMN valuntil SET DATA TYPE timestamptz;
-    -- Now update the pem.probe_column itself
-    UPDATE pem.probe_column
-    SET sql_data_type = ‘timestamptz’
-    WHERE sql_data_type = ‘abstime’ AND internal_name = ‘valuntil’;
-END;
-$$ LANGUAGE ‘plpgsql’;
-```
-
-- Replace the below function to avoid any alert errors:
-
-```text
-CREATE OR REPLACE FUNCTION pem.check_alert_params_array_size(
-template_id pem.alert_template.id%type, params text[]
-)
-RETURNS bool AS $FUNC$
-DECLARE
-    res bool := TRUE;
-BEGIN
-    /*
-     * During restoring the pem database, it does not maintain the order while
-     * inserting data in the table, and uses the sort table based on the
-     * names.
-     * Hence - we need to check the foreign key constraint is present before
-     * validating these values.
-     */
-    IF EXISTS(
-      SELECT 1 FROM information_schema.table_constraints
-      WHERE constraint_name='alert_template_id_fkey' AND
-      table_name='alert' AND table_schema='pem'
-    ) THEN
+    - The `abstime`, `reltime`, and `tinterval` datatypes are deprecated from Postgres version 12 or later, hence to replace those dataypes  with `timestamptz` data type use below command:
+
+    ```text
+    DO
+    $$
+    DECLARE
+        rec record;
+        cnt integer;
+    BEGIN
+        -- Check for the deprecated type in our user info probe
+        SELECT count(*) INTO cnt
+        FROM pem.probe_column
+        WHERE sql_data_type = ‘abstime’ AND internal_name = ‘valuntil’;
+            IF cnt = 0 THEN
+                RETURN;
+            END IF;
+        ALTER TABLE pemdata.user_info
+            ALTER COLUMN valuntil SET DATA TYPE timestamptz;
+        ALTER TABLE pemhistory.user_info
+            ALTER COLUMN valuntil SET DATA TYPE timestamptz;
+        -- Now update the pem.probe_column itself
+        UPDATE pem.probe_column
+        SET sql_data_type = ‘timestamptz’
+        WHERE sql_data_type = ‘abstime’ AND internal_name = ‘valuntil’;
+    END;
+    $$ LANGUAGE ‘plpgsql’;
+    ```
+
+    - Replace the below function to avoid any alert errors:
+
+    ```text
+    CREATE OR REPLACE FUNCTION pem.check_alert_params_array_size(
+    template_id pem.alert_template.id%type, params text[]
+    )
+    RETURNS bool AS $FUNC$
+    DECLARE
+        res bool := TRUE;
+    BEGIN
+        /*
+        * During restoring the pem database, it does not maintain the order while
+        * inserting data in the table, and uses the sort table based on the
+        * names.
+        * Hence - we need to check the foreign key constraint is present before
+        * validating these values.
+        */
+        IF EXISTS(
+            SELECT 1 FROM information_schema.table_constraints
+            WHERE constraint_name='alert_template_id_fkey' AND
+            table_name='alert' AND table_schema='pem'
+        ) THEN
       /*
        * Need to use the IS TRUE construct outside the main query, because
        * otherwise if there's no template by that ID then the query would return
@@ -83,10 +82,9 @@ BEGIN
       $SQL$ INTO res USING template_id, params;
     END IF;
      RETURN res;
-END
-$FUNC$ LANGUAGE 'plpgsql';
-```
-````
+    END
+    $FUNC$ LANGUAGE 'plpgsql';
+    ```
 
 `pg_upgrade` supports a transfer of data between servers of the same type. For example, you can use `pg_upgrade` to move data from a PostgreSQL 9.6 backend database to a PostgreSQL 11 backend database, but not to an Advanced Server 11 backend database. If you wish to migrate to a different type of backend database (i.e from a PostgreSQL server to Advanced Server), see [Moving the Postgres Enterprise Manager Server](03_moving_pem_server).
 

diff --git a/product_docs/docs/pem/8.0.1/pem_upgrade/03_moving_pem_server.mdx b/product_docs/docs/pem/8.0.1/pem_upgrade/03_moving_pem_server.mdx
@@ -80,11 +80,11 @@ Before starting the server migration, you should ensure that the firewalls betwe
 
         Note that invoking the `pg_dump` utility will not interrupt current database users.
 
-    !!! Note
-        If the source PEM Server is lower than the 7.16 version, then you need to replace the following functions before you run `pg_dump` to take backup:
+  !!! Note
+      If the source PEM Server is lower than the 7.16 version, then you need to replace the following functions before you run `pg_dump` to take backup:
 
-    ````
-    - The ``abstime``, ``reltime``, and ``tinterval`` datatypes are depreacated from Postgres version 12 or later, hence to replace those dataypes  with ``timestamptz`` data type use below 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 below command:
 
       ```text
       DO
@@ -112,7 +112,7 @@ Before starting the server migration, you should ensure that the firewalls betwe
       $$ LANGUAGE ‘plpgsql’;
       ```
 
-    - Replace the below function to avoid any alert errors:
+      - Replace the below function to avoid any alert errors:
 
       ```text
       CREATE OR REPLACE FUNCTION pem.check_alert_params_array_size(
@@ -157,7 +157,6 @@ Before starting the server migration, you should ensure that the firewalls betwe
       END
       $FUNC$ LANGUAGE 'plpgsql';
       ```
-    ````
 
 
 5.  Move the Backup to the Target Host

diff --git a/product_docs/docs/pem/8.0/pem_upgrade/02_upgrading_backend_database.mdx b/product_docs/docs/pem/8.0/pem_upgrade/02_upgrading_backend_database.mdx
@@ -8,15 +8,15 @@ legacyRedirectsGenerated:
 
 If you are updating both PEM components and the PEM backend database, you should perform PEM component updates (the server and Agent) before updating the backend database. For more information about updating PEM component software, see [Upgrading a PEM Installation](01_upgrading_pem_installation/#upgrading_pem_installation).
 
-!!! Note 
-From PEM 8.0 onwards, the PostgreSQL or EPAS version 11 or higher are only supported as backend database server. Hence if your backend database server is lower than version 11 then first you need to upgrade your backend database server and then upgrade the PEM components.
+!!! Note
+    From PEM 8.0 onwards, the PostgreSQL or EPAS version 11 or higher are only supported as backend database server. Hence if your backend database server is lower than version 11 then first you need to upgrade your backend database server and then upgrade the PEM components.
 
 The update process described in this section uses the `pg_upgrade` utility to migrate from one version of the backend server to a more recent version. `pg_upgrade` facilitates migration between any version of Postgres (version 9.5 or later), and any subsequent release of Postgres that is supported on the same platform.
 
 !!! Note
-If the source PEM Server is lower than the 7.16 version, then you need to replace the following functions before you run `pg_upgrade`:
+    If the source PEM Server is lower 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 depreacated from Postgres version 12 or later, hence to replace those dataypes  with `timestamptz` data type use below 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 following command:
 
     ```text
     DO
@@ -44,7 +44,7 @@ If the source PEM Server is lower than the 7.16 version, then you need to replac
     $$ LANGUAGE ‘plpgsql’;
     ```
 
-  - Replace the below function to avoid any alert errors:
+    - Replace the below function to avoid any alert errors:
 
     ```text
     CREATE OR REPLACE FUNCTION pem.check_alert_params_array_size(

diff --git a/product_docs/docs/pem/8.0/pem_upgrade/03_moving_pem_server.mdx b/product_docs/docs/pem/8.0/pem_upgrade/03_moving_pem_server.mdx
@@ -84,10 +84,10 @@ Before starting the server migration, you should ensure that the firewalls betwe
 
     Note that invoking the `pg_dump` utility will not interrupt current database users.
 
-   !!! Note 
-   If the source PEM Server is lower than the 7.16 version, then you need to replace the following functions before you run ``pg_dump`` to take backup:
+  !!! Note
+      If the source PEM Server is lower than the 7.16 version, then you need to replace the following functions before you run ``pg_dump`` to take backup:
 
-      - The ``abstime``, ``reltime``, and ``tinterval`` datatypes are depreacated from Postgres version 12 or later, hence to replace those dataypes  with ``timestamptz`` data type use below command:
+       - The ``abstime``, ``reltime``, and ``tinterval`` datatypes are depreacated from Postgres version 12 or later, hence to replace those dataypes  with ``timestamptz`` data type use below command:
 
         ```text
         DO
@@ -115,7 +115,7 @@ Before starting the server migration, you should ensure that the firewalls betwe
         $$ LANGUAGE ‘plpgsql’;
         ```
 
-      - Replace the below function to avoid any alert errors:
+       - Replace the below function to avoid any alert errors:
 
         ```text
         CREATE OR REPLACE FUNCTION pem.check_alert_params_array_size(