Skip to content

Commit

Permalink
Formatting for a note is fixed in PEM Upgrade guide
Browse files Browse the repository at this point in the history
Formatting for a note is fixed in PEM Upgrade guide


Former-commit-id: 148bb62
  • Loading branch information
nidhibhammar committed Mar 16, 2021
1 parent eaac9b8 commit f808ece
Show file tree
Hide file tree
Showing 4 changed files with 67 additions and 70 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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).

Expand Down
11 changes: 5 additions & 6 deletions product_docs/docs/pem/8.0.1/pem_upgrade/03_moving_pem_server.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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(
Expand Down Expand Up @@ -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
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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(
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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(
Expand Down

0 comments on commit f808ece

Please sign in to comment.