EnterpriseDB · djw-m · Jun 10, 2025 · May 9, 2025 · May 29, 2025 · Apr 22, 2025
@@ -50,7 +50,7 @@ jobs:
           draft_tag=`gh release list --repo EnterpriseDB/docs --limit 1 --json "isDraft,tagName" --jq '.[] | select(.isDraft) | .tagName'`
           if [[ -n "$draft_tag" ]]; then
             echo "Publishing draft release for: $draft_tag"
-            gh release edit "$draft_tag" --repo EnterpriseDB/docs --draft false
+            gh release edit "$draft_tag" --repo EnterpriseDB/docs --draft=false
           fi
 
       - uses: act10ns/slack@v2

@@ -157,7 +157,7 @@ cluster:
 
 Save it as `pgd-cli-config.yml`.
 
-See also [Installing PGD CLI](/pgd/latest/cli/installing/).
+See also [Installing PGD CLI](/pgd/latest/reference/cli/installing/).
 
 #### Installing Migration Toolkit
 

@@ -4,4 +4,4 @@ navTitle: Distributed High Availability
 description: The PGD defaults and commands for Distributed high availability on EDB Postgres AI Cloud Service.
 ---
 
-When running a distributed high-availability cluster on Cloud Service, you can use the [PGD CLI](/pgd/latest/cli/) to manage cluster operations. Examples of these operations include switching over write leaders, performing cluster health checks, and viewing various details about nodes, groups, or other aspects of the cluster.
+When running a distributed high-availability cluster on Cloud Service, you can use the [PGD CLI](/pgd/latest/reference/cli/) to manage cluster operations. Examples of these operations include switching over write leaders, performing cluster health checks, and viewing various details about nodes, groups, or other aspects of the cluster.
@@ -6,12 +6,12 @@ redirects:
   - /biganimal/latest/using_cluster/pgd_cli_ba/ #generated for BigAnimal URL path removal branch
 ---
 
-When running a distributed high-availability cluster on Cloud Service, you can use the [PGD CLI](/pgd/latest/cli/) to manage cluster operations. 
+When running a distributed high-availability cluster on Cloud Service, you can use the [PGD CLI](/pgd/latest/reference/cli/) to manage cluster operations.
 Examples of these operations include switching over write leaders, performing cluster health checks, and viewing various details about nodes, groups, or other aspects of the cluster.
 
 ## Installing the PGD CLI
 
-To [install the PGD CLI](/pgd/latest/cli/installing/), for Debian and Ubuntu machines, replace `<your-token>` with your EDB subscription token in the following command:
+To [install the PGD CLI](/pgd/latest/reference/cli/installing/), for Debian and Ubuntu machines, replace `<your-token>` with your EDB subscription token in the following command:
 
 ```bash
 curl -1sLf 'https://downloads.enterprisedb.com/<your-token>/postgres_distributed/setup.deb.sh' | sudo -E bash
@@ -31,11 +31,11 @@ sudo yum install edb-pgd5-cli
 
 To connect to your distributed high-availability Cloud Service cluster using the PGD CLI, you need to [discover the database connection string](/pgd/latest/cli/discover_connections/). From your Console:
 
-1.  Log in to the [Cloud Service clusters](https://portal.biganimal.com/clusters) view.
-2.  To show only clusters that work with PGD CLI, in the filter, set **Cluster Type** to **Distributed High Availability**.
-3.  Select your cluster.
-4.  In the view of your cluster, select the **Connect** tab.
-5.  Copy the read/write URI from the connection info. This is your connection string.
+1. Log in to the [Cloud Service clusters](https://portal.biganimal.com/clusters) view.
+2. To show only clusters that work with PGD CLI, in the filter, set **Cluster Type** to **Distributed High Availability**.
+3. Select your cluster.
+4. In the view of your cluster, select the **Connect** tab.
+5. Copy the read/write URI from the connection info. This is your connection string.
 
 ### Using the PGD CLI with your database connection string
 
@@ -109,4 +109,4 @@ __OUTPUT__
 Command executed successfully
 ```
 
-See the [PGD CLI command reference](/pgd/latest/cli/command_ref/) for the full range of PGD CLI commands and their descriptions. 
+See the [PGD CLI command reference](/pgd/latest/reference/cli/command_ref/) for the full range of PGD CLI commands and their descriptions. 
@@ -8,9 +8,9 @@ redirects:
 
 ## Commit scope
 
-[Commit scopes](/pgd/latest/commit-scopes/commit-scopes/) in PGD are a set of rules that describe the behavior of the system as transactions are committed. Because they define how transactions are replicated across a distributed database, they have an effect on consistency, durability, and performance.
+[Commit scopes](/pgd/latest/reference/commit-scopes/commit-scopes/) in PGD are a set of rules that describe the behavior of the system as transactions are committed. Because they define how transactions are replicated across a distributed database, they have an effect on consistency, durability, and performance.
 
-The actual behavior depends on the kind of commit scope a commit scope's rule uses: [Group Commit](/pgd/latest/commit-scopes/group-commit/), [Commit At Most Once](/pgd/latest/commit-scopes/camo/), [Lag Control](/pgd/latest/commit-scopes/lag-control/), [Synchronous Commit](/pgd/latest/commit-scopes/synchronous_commit/), or a combination of these.
+The actual behavior depends on the kind of commit scope a commit scope's rule uses: [Group Commit](/pgd/latest/reference/commit-scopes/group-commit/), [Commit At Most Once](/pgd/latest/reference/commit-scopes/camo/), [Lag Control](/pgd/latest/reference/commit-scopes/lag-control/), [Synchronous Commit](/pgd/latest/reference/commit-scopes/synchronous_commit/), or a combination of these.
 
 This flexibility means that selecting a balanced combination of rules can take time. To speed up deployment, Cloud Service's PGD has a preset selection of commit scopes for typical user requirements. These presets don't prevent you from creating and applying your own commit scopes as needed.
 
@@ -137,4 +137,4 @@ SELECT bdr.alter_node_group_option(
 Commit scopes can be applied per transaction. In that case, they override a Cloud Service preset. 
 !!!
 
-For more information, see [Commit scopes](/pgd/latest/commit-scopes/commit-scopes/) and [Commit scope rules](/pgd/latest/commit-scopes/commit-scope-rules/) in the PGD documentation.
+For more information, see [Commit scopes](/pgd/latest/reference/commit-scopes/commit-scopes/) and [Commit scope rules](/pgd/latest/reference/commit-scopes/commit-scope-rules/) in the PGD documentation.
@@ -11,15 +11,15 @@ This configuration provides a true active-active solution as each data group is
 
 Distributed high-availability clusters support both EDB Postgres Advanced Server and EDB Postgres Extended Server database distributions. 
 
-Distributed high-availability clusters contain one or two data groups. Your data groups can contain either three data nodes or two data nodes and one witness node. At any given time, one of these data nodes in each group is the leader and accepts writes, while the rest are referred to as [shadow nodes](/pgd/latest/terminology/#write-leader). We recommend that you don't use two data nodes and one witness node in production unless you use asynchronous [commit scopes](/pgd/latest/commit-scopes/commit-scopes/). 
+Distributed high-availability clusters contain one or two data groups. Your data groups can contain either three data nodes or two data nodes and one witness node. At any given time, one of these data nodes in each group is the leader and accepts writes, while the rest are referred to as [shadow nodes](/pgd/latest/terminology/#write-leader). We recommend that you don't use two data nodes and one witness node in production unless you use asynchronous [commit scopes](/pgd/latest/reference/commit-scopes/commit-scopes/). 
 
 [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. It supports operations that require a consensus, for example, in case of an availability zone failure. 
 
 !!!Note
 
-   Operations against a distributed high-availability cluster leverage the [EDB Postgres Distributed set-leader](/pgd/latest/cli/command_ref/group/set-leader) feature, which provides subsecond interruptions during planned lifecycle operations.
+   Operations against a distributed high-availability cluster leverage the [EDB Postgres Distributed set-leader](/pgd/latest/reference/cli/command_ref/group/set-leader) feature, which provides subsecond interruptions during planned lifecycle operations.
 
 ## Single data location
 

@@ -67,11 +67,11 @@ Refer to the [Rubrik Partner Page](https://www.enterprisedb.com/partners/rubrik
 
 EDB Postgres AI leads the way for applications that require high availability for critical business continuity. With [EDB Postgres Distributed (PGD)](https://www.enterprisedb.com/products/edb-postgres-distributed), customers can build [geo-distributed](https://www.enterprisedb.com/use-case/geo-distributed) architectures that ensure continuous availability, improve performance by placing data closer to users, and enable safe, zero-downtime software deployments.
 
-The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/latest/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with [third party change data capture (CDC) functionality](https://www.enterprisedb.com/docs/pgd/latest/cdc-failover/). This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication.
+The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/latest/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with [third party change data capture (CDC) functionality](https://www.enterprisedb.com/docs/pgd/5.7/cdc-failover/). This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication.
 
-Additionally, the new [`Assess`](https://www.enterprisedb.com/docs/pgd/latest/cli/command_ref/assess/) command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD.
+Additionally, the new `Assess` command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD.
 
-PGD 5.7.0 also introduces the [`pgd node upgrade`](https://www.enterprisedb.com/docs/pgd/latest/cli/command_ref/node/upgrade/) command, which enables upgrades to the latest versions of PGD and PostgreSQL with a single command, limiting the manual work required for maintenance and reducing complexity and potential errors. These updates collectively enhance the robustness and usability of PGD to provide users with a more reliable and efficient data management experience.
+PGD 5.7.0 also introduces the `pgd node upgrade` command, which enables upgrades to the latest versions of PGD and PostgreSQL with a single command, limiting the manual work required for maintenance and reducing complexity and potential errors. These updates collectively enhance the robustness and usability of PGD to provide users with a more reliable and efficient data management experience.
 
 Learn more about how [PGD](https://www.enterprisedb.com/products/edb-postgres-distributed) enables high availability for enterprise applications.
 

@@ -73,11 +73,11 @@ Refer to the [Rubrik Partner Page](https://www.enterprisedb.com/partners/rubrik
 
 EDB Postgres AI leads the way for applications that require high availability for critical business continuity. With [EDB Postgres Distributed (PGD)](https://www.enterprisedb.com/products/edb-postgres-distributed), customers can build [geo-distributed](https://www.enterprisedb.com/use-case/geo-distributed) architectures that ensure continuous availability, improve performance by placing data closer to users, and enable safe, zero-downtime software deployments.
 
-The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/latest/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with [third party change data capture (CDC) functionality](https://www.enterprisedb.com/docs/pgd/latest/cdc-failover/). This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication.
+The latest version, [PGD 5.7.0](https://www.enterprisedb.com/docs/pgd/5.7/), is now generally available. It delivers up to 99.999% availability with improved reliability and streamlined operations through enhanced integration with third party change data capture (CDC) functionality. This allows seamless failover of logical slots for common CDC plugins like `test_decoding` and `pgoutput`, eliminating the need for third party subscribers to reseed tables during lead primary changes and ensuring continuous data replication.
 
-Additionally, the new [`Assess`](https://www.enterprisedb.com/docs/pgd/latest/cli/command_ref/assess/) command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD.
+Additionally, the new `Assess` command in the PGD CLI ensures seamless migrations to PGD. The tool proactively identifies PostgreSQL incompatibilities before upgrades, especially those impacting logical replication, so you can address them before upgrading to PGD.
 
-PGD 5.7.0 also introduces the [`pgd node upgrade`](https://www.enterprisedb.com/docs/pgd/latest/cli/command_ref/node/upgrade/) command, which enables upgrades to the latest versions of PGD and PostgreSQL with a single command, limiting the manual work required for maintenance and reducing complexity and potential errors. These updates collectively enhance the robustness and usability of PGD to provide users with a more reliable and efficient data management experience.
+PGD 5.7.0 also introduces the `pgd node upgrade` command, which enables upgrades to the latest versions of PGD and PostgreSQL with a single command, limiting the manual work required for maintenance and reducing complexity and potential errors. These updates collectively enhance the robustness and usability of PGD to provide users with a more reliable and efficient data management experience.
 
 Learn more about how [PGD](https://www.enterprisedb.com/products/edb-postgres-distributed) enables high availability for enterprise applications.
 

@@ -26,6 +26,11 @@ Before you begin the installation process:
 
   To set up the repository, go to [EDB repositories](https://www.enterprisedb.com/repos-downloads) and follow the instructions provided there.
 
+  If you are using RHEL 9, you also need to install the EPEL repository:
+  ```shell
+  sudo dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
+  ```
+
 
 ### Install the package
 

@@ -43,6 +43,8 @@ The following custom GUCs control the EDB Postgres Tuner `work_mem` tuning behav
 
 - `edb_pg_tuner.buffer_size` &mdash; Maximum query count for tracking statistics. The default is 5000.
 
+- `edb_pg_tuner.container_memory_limit_file_path` &mdash; Specifies the path to the file that contains the memory limit set by the container runtime, such as Docker or Kubernetes. This file is read by `edb_pg_tuner` to determine the maximum amount of memory available to the database process when running inside a container. Based on this limit, the tuner can generate optimised PostgreSQL configuration recommendations that are container-aware. The file is at `/sys/fs/cgroup/memory/memory.limit_in_bytes` by default.
+
 ## Recommended GUCs
 
 EDB Postgres Tuner can recommend the following GUCs. The `static` category provides fixed recommendation settings. The `dynamic` category uses specific algorithms to suggest a better setting according to your workload or hardware resources.

@@ -1,28 +1,27 @@
 ---
-title: CloudNativePG
+title: CloudNativePG™
 navTitle: CloudNativePG
 navRootedTo: /edb-postgres-ai/platforms-and-tools/kubernetes
-description: EDB supports CloudNativePG.
+description: EDB supports CloudNativePG™.
 directoryDefaults:
   iconName: logos/KubernetesMono
   product: CloudNativePG
 
 ---
 
-CloudNativePG is the Kubernetes operator that covers the full lifecycle of a highly available Postgres database cluster with a primary/standby architecture, using native streaming replication.
+CloudNativePG™ is the Kubernetes operator that covers the full lifecycle of a highly available Postgres database cluster with a primary/standby architecture, using native streaming replication.
 
 !!! Note
-    Looking for CloudNativePG documentation? Head over to [cloudnative-pg.io/docs/](https://cloudnative-pg.io/docs/).
+    Looking for CloudNativePG™ documentation? Head over to [cloudnative-pg.io/docs/](https://cloudnative-pg.io/docs/).
 
-CloudNativePG was originally built by EDB, then released open source under Apache License 2.0 and submitted for CNCF Sandbox in April 2022. The source code repository is in [Github](https://github.com/cloudnative-pg/cloudnative-pg).
+CloudNativePG™ was originally built by EDB, then released open source under Apache License 2.0 and submitted for CNCF Sandbox in April 2022. The source code repository is in [Github](https://github.com/cloudnative-pg/cloudnative-pg).
 
 Key features available include:
+
 - Kubernetes API integration for high availability
 - Self-healing through failover and automated recreation of replicas
 - Capacity management with scale up/down capabilities
 - Planned switchovers for scheduled maintenance
 - Read-only and read-write Kubernetes services definitions
 - Rolling updates for Postgres minor versions and operator upgrades
 - Continuous backup and point-in-time recovery
-
-
@@ -108,6 +108,12 @@ exports.onCreateNode = async ({
       });
     }
 
+    if (node.extension === "sh") {
+      await makeFileNodePublic(node, createNodeId, actions, {
+        mimeType: "text/plain",
+      });
+    }
+
     // these are a template of sorts, used to generate a function index for a reference section
     // see tools/automation/generators/refbuilder/refbuilder.js for details
     if (node.absolutePath.endsWith("index.mdx.src")) {

@@ -18,6 +18,6 @@ redirects:
 
 **Required authorization to activate:** EDB Postgres Advanced Server service account
 
-`max_wal_size` specifies the maximum size for the WAL to reach between automatic WAL checkpoints. This is a soft limit. WAL size can exceed `max_wal_size` under special circumstances, such as when under a heavy load, with a failing archive_command, or with a high `wal_keep_segments` setting.
+`max_wal_size` specifies the maximum size for the WAL to reach between automatic WAL checkpoints. This is a soft limit. WAL size can exceed `max_wal_size` under special circumstances, such as when under a heavy load, with a failing archive_command, or with a high `wal_keep_size` setting.
 
 Increasing this parameter can increase the amount of time needed for crash recovery. You can set this parameter in the `postgresql.conf` file or on the server command line.