Merge pull request #6139 from EnterpriseDB/release/2024-10-07a

Release: 2024-10-07a

advocacy_docs/dev-guides/deploy/windows.mdx

@@ -1,6 +1,6 @@
 ---
 title: Installing PostgreSQL for development and testing on Microsoft Windows
-navTitle: On Windows
+navTitle: Windows
 description: Install PostgreSQL on your local Windows machine for development purposes.
 product: postgresql
 iconName: logos/Windows

advocacy_docs/dev-guides/index.mdx

@@ -18,6 +18,8 @@ The EDB Postgres AI Developer Guides are all about providing you, the developer,
 
 * [Deploying Postgres Using Docker Locally](deploy/docker)
 
+* [Deploying PostgreSQL for development and testing on Microsoft Windows](deploy/windows)
+
 ## Working with Postgres
 
 * [PSQL for busy developers](working/psql-for-busy-developers)

advocacy_docs/partner_docs/ThalesCipherTrustManager/04-ConfiguringThalesCipherTrustManager.mdx

@@ -96,7 +96,7 @@ Complete!
 
 ## Configure Thales CipherTrust Manager for your EDB Postgres distribution
 
-After Thales CipherTrust Manger is up and running, create the required certificates.
+After Thales CipherTrust Manager is up and running, create the required certificates.
 
 ## Log in to Thales CipherTrust Manager and create user
 When creating a key on Thales CipherTrust Manager with an EDB Postgres distribution, you need to create a user for future authentication. This process verifies the username and password against the Thales CipherTrust Manager internal database.
@@ -178,4 +178,4 @@ These are the other two certificates you need for your KMIP server and `pykmip.c
 10. To download the final two certificates, select **Save Private Key**, and then select **Save Certificate**.  Make sure to note their downloaded location for later.
     ![Thales Download Certificate Files](Images/ThalesDownloadCerts.png)
 
-You are now ready to use Thales CipherTrust Manager and your EDB Postgres distribution with TDE for key management.
+You are now ready to use Thales CipherTrust Manager and your EDB Postgres distribution with TDE for key management.

product_docs/docs/efm/4/06_monitoring_efm_cluster.mdx

@@ -23,11 +23,11 @@ The `efm cluster-status` [cluster properties file](07_using_efm_utility/#efm_clu
 The following status report is for a cluster named edb that has three nodes running:
 
 ```text
-Agent Type  Address               Agent   DB        VIP
------------------------------------------------------------------------
-Standby     172.19.10.2            UP     UP        192.168.225.190
-Standby     172.19.12.163          UP     UP        192.168.225.190
-Primary     172.19.14.9            UP     UP        192.168.225.190*
+Agent Type  Address               DB        VIP
+---------------------------------------------------------------
+Standby     172.19.10.2           UP        192.168.225.190
+Standby     172.19.12.163         UP        192.168.225.190
+Primary     172.19.14.9           UP        192.168.225.190*
 
 
 Allowed node host list:
@@ -55,11 +55,11 @@ Standby database(s) in sync with primary. It is safe to promote.
 The cluster status section provides an overview of the status of the agents that reside on each node of the cluster:
 
 ```text
-Agent Type  Address             Agent   DB        VIP
------------------------------------------------------------------------
-Standby     172.19.10.2          UP     UP        192.168.225.190
-Standby     172.19.12.163        UP     UP        192.168.225.190
-Primary     172.19.14.9          UP     UP        192.168.225.190*
+Agent Type  Address             DB        VIP
+---------------------------------------------------------------
+Standby     172.19.10.2         UP        192.168.225.190
+Standby     172.19.12.163       UP        192.168.225.190
+Primary     172.19.14.9         UP        192.168.225.190*
 ```
 
 The asterisk (\*) after the VIP address indicates that the address is available for connections. If a VIP address is not followed by an asterisk, the address was associated with the node in the properties file, but the address isn't currently in use.
@@ -90,9 +90,9 @@ Standby  172.19.10.2     0/4000638          0/4000638
 If a database is down or if the database was restarted, but the resume command was not yet invoked, the state of the agent that resides on that host is idle. If an agent is idle, the cluster status report includes a summary of the condition of the idle node. For example:
 
 ```text
-Agent Type Address Agent DB VIP
------------------------------------------------------
-Idle 172.19.18.105 UP UP 172.19.13.105
+Agent Type  Address             DB        VIP
+---------------------------------------------------------------
+Idle        172.19.18.105       UP        172.19.13.105
 ```
 
 ### Exit codes

product_docs/docs/migration_portal/4/known_issues_notes.mdx

@@ -233,6 +233,8 @@ While using the Oracle default case, you may experience a lower compatibility ra
 
 ## EDB DDL Extractor
 
+### General limitations
+
 -   The EDB DDL Extractor script doesn't extract objects restored using `Flashback` that still have names like `BIN$b54+4XlEYwPgUAB/AQBWwA==$0`. If you want to extract these objects, you must change the names of the objects and rerun the extraction process.
 -   The EDB DDL Extractor extracts `nologging` tables as normal tables. Once these tables are migrated to EDB Postgres Advanced Server, WAL log files are created.
 -   The EDB DDL Extractor extracts objects only with `VALID` status. For any objects that have `INVALID` status that you want Migration Portal to assess, first update them to `VALID`.
@@ -243,6 +245,59 @@ While using the Oracle default case, you may experience a lower compatibility ra
 -   The EDB DDL Extractor currently doesn't support the extraction of `ROLES`, `SYSTEM GRANTS ON ROLES`, `OBJECT GRANTS ON ROLES`, and `ROLE GRANTS` from Oracle 11g. This behavior results in error messages being written to the extracted files in the sections corresponding to these object types. These errors don't cause any issue in the assessment of these files by Migration Portal.
 -   The EDB DDL Extractor script may log `object "OBJECT_NAME" of type SYNONYM not found in schema "PUBLIC"` errors in the dependent objects section of the extracted file. This happens only if the user selects the option to extract dependent objects from an Oracle multi tenant environment where the Oracle database is a container database.
 
+### "Snapshot Too Old" Error
+
+The EDB DDL Extractor displays the error “ORA-01555: snapshot too old“ at runtime when the database server generates a volume of transactions that cannot be properly processed by the UNDO tablespace.
+
+When the database server generates undo transactions at a high rate, it can cause the server to run out of space to store undo data. Since the UNDO tablespace is implemented as a circular buffer, it starts overwriting older undo data blocks. Resolve this error and rerun the EDB DDL Extractor to ensure you extract the DDLs without any errors.
+
+To work around this error, increase the allocated space for the UNDO_RETENTION parameter.
+
+First, check the currently allocated total space for undo operations and the currently free space:
+
+1.  Check the existing value of the UNDO_RETENTION parameter:
+
+    ```sql
+    SELECT value FROM v$parameter WHERE name = 'undo_retention';
+    ```
+
+1.  Add the results of the two following queries to check the total available space in the UNDO tablespace:
+
+    ```sql
+    SELECT SUM(bytes)/1024/1024 free_mb FROM dba_undo_extents WHERE status='EXPIRED';
+    ```
+
+    ```sql
+    SELECT dfs.tablespace_name, SUM(dfs.bytes) / 1024 / 1024 AS free_mb FROM 
+    dba_free_space dfs 
+    JOIN dba_tablespaces dt ON dfs.tablespace_name = dt.tablespace_name 
+    WHERE dt.contents = 'UNDO' GROUP BY dfs.tablespace_name; 2 3 4
+    ```
+
+Next, determine the number of MB your environment requires and increase the allocated storage space:
+
+1.  Monitor the volume of undo data generated by transactions during peak usage hours:
+
+    ```sql
+    SELECT SUM(undoblks * 8192)/1024/1024 AS undo_mbs FROM v$undostat;
+    ```
+
+    !!!note 
+    The value reflects the number of undo blocks consumed during a 10-minute interval, then converted into MB.
+    !!!
+
+1.  Calculate the total number of MB your environment requires for the UNDO tablespace. For example, if the transaction volume generates X MB of undo data per minute, and the requirement is to retain the data for Y minutes:
+
+    UNDO Space (MB) = X (MB/min) × Y (min)
+
+1.  Update the UNDO_RETENTION parameter according to the required space in MB. This example increases the storage space to 2400 MB.
+
+    ```sql
+    ALTER SYSTEM SET UNDO_RETENTION = 2400;
+    __OUTPUT__
+    System altered.
+    ```
+
 ## Oracle Data Pump utilities
 
 - Migration Portal might fail to parse your SQL file if you create a database link using the `IDENTIFIED BY` clause with Oracle's quote operator, for example, `IDENTIFIED BY VALUES q'[:1]'`. To parse your file successfully, try using an actual password, for example, `IDENTIFIED BY my_password`.

product_docs/docs/pgd/5/appusage/extensions.mdx

@@ -6,25 +6,25 @@ deepToC: true
 
 ## PGD and other PostgreSQL extensions
 
-PGD is implemented as a PostgreSQL extension (see [Supported Postgres database servers](../overview/#supported-postgres-database-servers)), taking advantage of PostgreSQL's expandability and flexibility to modify low level system behavior to provide multi-master replication.
+PGD is implemented as a PostgreSQL extension (see [Supported Postgres database servers](../overview/#supported-postgres-database-servers)). It takes advantage of PostgreSQL's expandability and flexibility to modify low-level system behavior to provide multi-master replication.
 
-In principle other extensions - both those provided by community PostgreSQL and EPAS, as well as third-party extensions, can be used together with PGD, however the distributed nature of PGD means selection and installation of extensions should be carefully considered and planned.
+In principle, extensions provided by community PostgreSQL, EDB Postgres Advanced Server, and third-party extensions can be used with PGD. However, the distributed nature of PGD means that you need to carefully consider and plan the extensions you select and install.
 
 ### Extensions providing logical decoding
 
-Extensions providing logical decoding, such as [wal2json](https://github.com/eulerto/wal2json), may in theory work with PGD, but there is no support for failover, meaning any WAL stream being read from such an extension may be interrupted.
+Extensions providing logical decoding, such as [wal2json](https://github.com/eulerto/wal2json), may in theory work with PGD. However, there's no support for failover, meaning any WAL stream being read from such an extension can be interrupted.
 
-### Extensions providing replication and/or HA functionality
+### Extensions providing replication or HA functionality
 
-Any extension extending PostgreSQL with functionality related to replication and/or HA/failover is unlikely to work well with PGD, and may even be detrimental to the health of the PGD cluster, so should be avoided.
+Any extension extending PostgreSQL with functionality related to replication or HA/failover is unlikely to work well with PGD and may even be detrimental to the health of the PGD cluster. We recommend avoiding these.
 
 ## Supported extensions
 
-This section lists extensions which are explicitly supported by PGD.
+These extensions are explicitly supported by PGD.
 
-### EDB Advanced Server Table Access methods
+### EDB Advanced Storage table access methods
 
-The [EDB Advanced Storage Pack](/pg_extensions/advanced_storage_pack/) provides a selection of table access methods (TAMs) implemented as extensions of which the following are certified for use with PGD:
+The [EDB Advanced Storage Pack](/pg_extensions/advanced_storage_pack/) provides a selection of table access methods (TAMs) implemented as extensions. The following TAMs are certified for use with PGD:
 
  - [Autocluster](/pg_extensions/advanced_storage_pack/#autocluster)
  - [Refdata](/pg_extensions/advanced_storage_pack/#refdata)
@@ -33,45 +33,44 @@ For more details, see [Table access methods](table-access-methods).
 
 ### pgaudit
 
-PGD has been modified to ensure compatibility with the [pgaudit](https://www.pgaudit.org/) extension.
+PGD was modified to ensure compatibility with the [pgaudit](https://www.pgaudit.org/) extension.
 See [Postgres settings](../postgres-configuration/#postgres-settings) for configuration information.
 
 
 ## Installing extensions
 
-PostgreSQL extensions provide SQL objects such as functions and datatypes, and optionally also one or more shared libraries, which must be loaded into the PostgreSQL backend before the extension can be installed and used.
+PostgreSQL extensions provide SQL objects, such as functions, datatypes, and, optionally, one or more shared libraries. These must be loaded into the PostgreSQL backend before you can install and use the extension.
 
 !!! Warning
 
-    The relevant extension packages must be available on all nodes in the cluster, otherwise extension installation may fail and impact cluster stability.
+    The relevant extension packages must be available on all nodes in the cluster. Otherwise extension installation can fail and impact cluster stability.
 
-If PGD is deployed using [Trusted Postgres Architect](/tpa/latest/), extensions should be configured via that. 
-For more details see [Adding Postgres extensions](/tpa/latest/reference/postgres_extension_configuration).
+If PGD is deployed using [Trusted Postgres Architect](/tpa/latest/), configure extensions using that tool. 
+For details, see [Adding Postgres extensions](/tpa/latest/reference/postgres_extension_configuration).
 
-The following sections are relevant for manually configured PGD installations.
+The following is relevant for manually configured PGD installations.
 
-### Configuring "shared_preload_libraries"
+### Configuring shared_preload_libraries
 
-If an extension provides a shared library, this library must be included in the [shared_preload_libraries](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-SHARED-PRELOAD-LIBRARIES) configuration parameter before the extension itself is installed.
+If an extension provides a shared library, include this library in the [`shared_preload_libraries`](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-SHARED-PRELOAD-LIBRARIES) configuration parameter before installing the extension.
 
 `shared_preload_libraries` consists of a comma-separated list of extension names. 
-It must include the `bdr` extension. 
-The order in which other extensions are specified is generally unimportant, however if using the `pgaudit` extension, `pgaudit` **must** appear in the list before `bdr`.
+It must include `bdr`.
+The order in which you specify other extensions generally doesn't matter. However if you're using the pgaudit extension, `pgaudit` must appear in the list before `bdr`.
 
-`shared_preload_libraries` should be configured on all nodes in the cluster before installing the extension with `CREATE EXTENSION`. 
-Note that it requires a PostgreSQL restart to activate the new configuration.
+Configure `shared_preload_libraries` on all nodes in the cluster before installing the extension with `CREATE EXTENSION`.
+You must restart PostgreSQL to activate the new configuration.
 
 See also [Postgres settings](../postgres-configuration/#postgres-settings).
 
 
 ### Installing the extension
 
-The extension itself is installed with the `CREATE EXTENSION` command. 
-This only needs to be carried out on one node in the cluster - PGD's DDL replication will ensure that it propagates to all other nodes.
+Install the extension using the `CREATE EXTENSION` command. 
+You need to do this on only one node in the cluster. PGD's DDL replication will ensure that it propagates to all other nodes.
 
 !!! Warning
 
-    Do not attempt to install extensions manually on each node by e.g. disabling DDL replication before executing `CREATE EXTENSION`.
+    Do not attempt to install extensions manually on each node by, for example, disabling DDL replication before executing `CREATE EXTENSION`.
 
     Do not use a command such as `bdr.replicate_ddl_command()` to execute `CREATE EXTENSION`.
-

product_docs/docs/pgd/5/appusage/index.mdx

@@ -33,7 +33,7 @@ Developing an application with PGD is mostly the same as working with any Postgr
 
 * [Timing considerations](timing) shows how the asynchronous/synchronous replication might affect an application's view of data and notes functions to mitigate stale reads.
 
-* [Extension usage](extensions) explains how to select and install extensions on PGD and configure them.
+* [Extension usage](extensions) explains how to select, install, and configure extensions on PGD.
 
 * [Table access methods](table-access-methods) (TAMs) notes the TAMs available with PGD and how to enable them.
 

product_docs/docs/pgd/5/node_management/creating_and_joining.mdx

@@ -56,9 +56,9 @@ The node that's joining the cluster must not contain any schema or data
 that already exists on databases in the PGD group. We recommend that the
 newly joining database be empty except for the BDR extension. However,
 it's important that all required database users and roles are created.
-Additionally, if the joining operation is to be carried out by a non-superuser,
-extensions requiring superuser permission will need to be manually created. For
-more details see [Connections and roles](../security/role-management#connections-and-roles).
+Also, if a non-superuser is performing the joining operation,
+extensions that require superuser permission must be created manually. For
+more details, see [Connections and roles](../security/role-management#connections-and-roles).
 
 Optionally, you can skip the schema synchronization using the
 `synchronize_structure` parameter of the

product_docs/docs/pgd/5/reference/functions-internal.mdx

@@ -165,7 +165,7 @@ This function removes the metadata for a given node from the local
 database. The node can be either:
 
 -   The local node, in which case it removes all the node metadata, including information about remote nodes.
--   A remote node, in which case it only removes metadata for that specific node.
+-   A remote node, in which case it removes only metadata for that specific node.
 
 
 
@@ -174,10 +174,10 @@ Do not use `bdr.drop_node()` to drop node metadata and reuse node names. PGD can
 
 Use of this internal function is limited to:
 
-* when you are instructed to by EDB Technical Support, or
-* where you are specifically instructed in the documentation to use `bdr.drop_node`.
+* When you're instructed to by EDB Technical Support.
+* Where you're specifically instructed to in the documentation.
 
-You should use [`bdr.part_node`](/pgd/latest/reference/nodes-management-interfaces#bdrpart_node) to remove a node from a PGD group. That function sets the node to `PARTED` state and enable reuse of the node name.
+Use [`bdr.part_node`](/pgd/latest/reference/nodes-management-interfaces#bdrpart_node) to remove a node from a PGD group. That function sets the node to `PARTED` state and enables reuse of the node name.
 
 !!!
 

product_docs/docs/pgd/5/security/role-management.mdx

@@ -53,22 +53,22 @@ nodes, such that following stipulations are satisfied:
 -   It owns all database objects to replicate, either directly or from
     permissions from the owner roles.
 
-Additionally, if any non-default extensions (excluding the `bdr` extension
-itself) are present on the source node, and any of these can only be installed
-by a superuser, these extensions must be created manually (by a superuser) on
-the join target node, otherwise the join process will fail.
+Also, if any non-default extensions (excluding the BDR extension) 
+are present on the source node, and any of these can be installed only
+by a superuser, a superuser must create these extensions manually on
+the join target node. Otherwise the join process will fail.
 
-In PostgreSQL 13 and later, extensions requiring superuser permission and which
-therefore need to be manually installed, can be identified by executing (on the
-source node):
+In PostgreSQL 13 and later, you can identify the extensions requiring superuser permission and
+that must be manually installed. On the
+source node, execute:
 
 ```sql
     SELECT name, (trusted IS FALSE AND superuser) AS superuser_only
       FROM pg_available_extension_versions
      WHERE installed AND name != 'bdr';
 ```
 
-Once all nodes are joined, to continue to allow DML and DDL replication, you can reduce the permissions further to the following:
+Once all nodes are joined, to continue to allow DML and DDL replication, you can further reduce the permissions to the following:
 
 -   The user has the `REPLICATION` attribute.
 -   It inherits the bdr_superuser role.