Docs 1438 connection manager documentation

product_docs/docs/pgd/6/cli/command_ref/group/get-option.mdx

@@ -25,7 +25,7 @@ And `<OPTION>` is the name of a specific group option you want to get. If no opt
 | apply_delay                | The delay in applying changes to the group.                    |
 | check_constraints          | Whether to check constraints in the group.                     |
 | default_commit_scope       | The default commit scope of the group.                         |
-| enable_proxy_routing       | Whether to enable proxy routing in the group.                  |
+| enable_routing             | Whether to enable routing in the group.                        |
 | enable_raft                | Whether to enable Raft in the group.                           |
 | enable_wal_decoder         | Whether to enable the WAL decoder in the group.                |
 | location                   | The location of the group.                                     |

product_docs/docs/pgd/6/cli/command_ref/group/set-option.mdx

@@ -27,7 +27,7 @@ The following options are available:
 | apply_delay                | The delay in applying changes to the group.                    |
 | check_constraints          | Whether to check constraints in the group.                     |
 | default_commit_scope       | The default commit scope of the group.                         |
-| enable_proxy_routing       | Whether to enable proxy routing in the group.                  |
+| enable_routing             | Whether to enable routing in the group.                        |
 | enable_raft                | Whether to enable Raft in the group.                           |
 | enable_wal_decoder         | Whether to enable the WAL decoder in the group.                |
 | location                   | The location of the group.                                     |

product_docs/docs/pgd/6/cli/installing/linux.mdx

@@ -39,7 +39,7 @@ Executing the  setup script for the 'enterprisedb/postgres_distributed' reposito
 You can now install the PGD CLI package using the command:
 
 ```shell
-sudo apt-get install edb-pgd5-cli
+sudo apt-get install edb-pgd6-cli
 ```
 
 ## Install on RHEL, Rocky, AlmaLinux, or Oracle Linux
@@ -60,7 +60,7 @@ Executing the  setup script for the 'enterprisedb/postgres_distributed' reposito
 You can now install the PGD CLI package using the command:
 
 ```shell
-sudo yum install edb-pgd5-cli
+sudo yum install edb-pgd6-cli
 ```
 
 [Next: Using PGD CLI](../using_cli)

product_docs/docs/pgd/6/cli/installing/postgres-configuration.mdx

@@ -0,0 +1,66 @@
+---
+title: Installing PGD CLI on Linux
+navTitle: Linux
+description: Installing PGD CLI on Linux
+---
+
+ PGD CLI is available for most Linux distributions. You can install it from the EDB repositories, which you can access with your EDB account. PGD users and EDB Cloud Service users, including those on a free trial, have an EDB account and access to PGD CLI.
+
+## Obtain your EDB subscription token
+
+These repositories require a token to enable downloads from them. To obtain your token, log in to [EDB Repos 2.0](https://www.enterprisedb.com/repos-downloads). If this is your first time visiting the EDB Repos 2.0 page, you must select **Request Access** to generate your token. Once a generated token is available, select the **Copy** icon to copy it to your clipboard, or select the eye icon to view it.
+
+## Set the EDB_SUBSCRIPTION_TOKEN environment variable
+
+Once you have the token, execute the command shown for your operating system, substituting
+your token for `<your-token>`.
+
+```shell
+export EDB_SUBSCRIPTION_TOKEN=<your-token>
+```
+
+Then run the appropriate commands for your operating system.
+
+## Install on Debian or Ubuntu
+
+```bash
+curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.deb.sh" | sudo -E bash
+```
+
+If this command returns an error like `curl: (22) The requested URL returned error: 404`, check that you entered the correct token.
+
+When the command is successful, you'll see output like this:
+
+```console
+Executing the  setup script for the 'enterprisedb/postgres_distributed' repository ...
+...
+```
+
+You can now install the PGD CLI package using the command:
+
+```shell
+sudo apt-get install edb-pgd6-cli
+```
+
+## Install on RHEL, Rocky, AlmaLinux, or Oracle Linux
+
+```bash
+curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/postgres_distributed/setup.rpm.sh" | sudo -E bash
+```
+
+If this command returns an error like `curl: (22) The requested URL returned error: 404`, check that you entered the correct token.
+
+When the command is successful, you'll see output like this:
+
+```console
+Executing the  setup script for the 'enterprisedb/postgres_distributed' repository ...
+...
+```
+
+You can now install the PGD CLI package using the command:
+
+```shell
+sudo yum install edb-pgd6-cli
+```
+
+[Next: Using PGD CLI](../using_cli)

product_docs/docs/pgd/6/commit-scopes/camo.mdx

@@ -78,7 +78,7 @@ This doesn't allow COMMIT status to be retrieved, but it does let you choose ava
 
 For a CAMO partner to switch to ready, it needs to be connected, and the estimated catchup interval needs to drop below the `timeout` value of `TO ASYNC`. You can check the current readiness status of a CAMO partner with [`bdr.is_camo_partner_ready()`](/pgd/latest/reference/functions#bdris_camo_partner_ready), while [`bdr.node_replication_rates`](/pgd/latest/reference/catalogs-visible#bdrnode_replication_rates) provides the current estimate of the catchup time.
 
-The switch from CAMO-protected to asynchronous mode is only ever triggered by an actual CAMO transaction. This is true either because the commit exceeds the `timeout` value of `TO ASYNC` or, in case the CAMO partner is already known, disconnected at the time of commit. This switch is independent of the estimated catchup interval. If the CAMO pair is configured to require the current node to be the write lead of a group as configured through the `enable_proxy_routing` node group option. See [Commit scopes](commit-scopes) for syntax. This can prevent a split brain situation due to an isolated node from switching to asynchronous mode. If `enable_proxy_routing` isn't set for the CAMO group, the origin node switches to asynchronous mode immediately.
+The switch from CAMO-protected to asynchronous mode is only ever triggered by an actual CAMO transaction. This is true either because the commit exceeds the `timeout` value of `TO ASYNC` or, in case the CAMO partner is already known, disconnected at the time of commit. This switch is independent of the estimated catchup interval. If the CAMO pair is configured to require the current node to be the write lead of a group as configured through the `enable_routing` node group option. See [Commit scopes](commit-scopes) for syntax. This can prevent a split brain situation due to an isolated node from switching to asynchronous mode. If `enable_routing` isn't set for the CAMO group, the origin node switches to asynchronous mode immediately.
 
 
 The switch from asynchronous mode to CAMO mode depends on the CAMO partner node, which initiates the connection. The CAMO partner tries to reconnect at least every 30 seconds. After connectivity is reestablished, it might therefore take up to 30 seconds until the CAMO partner connects back to its origin node. Any lag that accumulated on

product_docs/docs/pgd/6/commit-scopes/group-commit.mdx

@@ -206,9 +206,6 @@ SELECT bdr.create_commit_scope(
 );
 ```
 
-!!! note Upgrading?
-    The old `global` commit scope doesn't exist anymore. The above command creates a scope that's the same as the old `global` scope with `bdr.global_commit_timeout` set to `60s`.
-
 The commit scope group for the Eager conflict resolution rule can only be `ALL` or `MAJORITY`. Where `ALL` is used, the `commit_decision` setting must also be set to `raft`.
 
 ### Error handling

product_docs/docs/pgd/6.0/connection-manager/configuring.mdx → product_docs/docs/pgd/6/connection-manager/configuring.mdx

@@ -30,5 +30,7 @@ Connection Manager takes its configuration from the PGD Group options for the gr
 
 ## Configuring authentication
 
-Connection Manager is configured through Postgres's own `pg_hba.conf` file. 
+Connection Manager's authentication is configured through Postgres's own `pg_hba.conf` file.
+
+
 

product_docs/docs/pgd/6/connection-manager/overview.mdx

@@ -0,0 +1,11 @@
+---
+title: Connection Manager overview
+navTitle: Overview
+description: Overview of the Connection Manager
+---
+
+## What is Connection Manager?
+
+Connection Manager is a new background worker for EDB Postgres Distributed (PGD) 6.0 that simplifies the process of connection to PGD clusters by providing a single point of entry for client applications. It replaces the previous proxy solution with an integrated approach that exposes read-write, read-only, and HTTP status network interfaces in PGD.
+
+Connection Manager is fully integrated into PGD and is designed to work seamlessly with the existing PGD architecture. 

product_docs/docs/pgd/6/ddl/ddl-locking.mdx

@@ -78,6 +78,8 @@ explained in [Executing DDL on PGD systems](ddl-overview#executing-ddl-on-pgd-sy
 
 -   `ddl_locking = all` takes global DDL lock and, if needed, takes relation DML lock.
 -   `ddl_locking = dml` skips global DDL lock and, if needed, takes relation DML lock.
+-   `ddl_locking = leader` enables leader-based global DML locking.
+-   `ddl_locking = auto` current behaves like `ddl_locking = leader`.
 -   `ddl_locking = off` skips both global DDL lock and relation DML lock.
 
 Some PGD functions make DDL changes. For those functions,

product_docs/docs/pgd/6/deploy-config/deploy-manual/deploying/01-provisioning-hosts.mdx → product_docs/docs/pgd/6/deploy-config/deploy-manual/01-prerequisites.mdx

@@ -1,10 +1,6 @@
 ---
-title: Step 1 - Provisioning hosts
-navTitle: Provisioning hosts
-deepToC: true
-redirects:
-  - /pgd/latest/install-admin/admin-manual/installing/01-provisioning-hosts/ #generated for pgd deploy-config-planning reorg 
-  - /pgd/latest/admin-manual/installing/01-provisioning-hosts/ #generated for pgd deploy-config-planning reorg 
+title: Prereqiuisites for manual deployment
+navTitle: Prerequisites
 ---
 
 ## Provisioning hosts
@@ -15,9 +11,9 @@ You can deploy to virtual machine instances in the cloud with Linux installed, o
 
 Whichever [supported Linux operating system](https://www.enterprisedb.com/resources/platform-compatibility#bdr) and whichever deployment platform you select, the result of provisioning a machine must be a Linux system that you can access using SSH with a user that has superuser, administrator, or sudo privileges.
 
-Each machine provisioned must be able to make connections to any other machine you're provisioning for your cluster. 
+Each machine provisioned must be able to make connections to any other machine you're provisioning for your cluster.
 
-On cloud deployments, you can do this over the public network or over a VPC. 
+On cloud deployments, you can do this over the public network or over a VPC.
 
 On-premises deployments must be able to connect over the local network.
 
@@ -47,32 +43,29 @@ With the admin user created, ensure that each machine can communicate with the o
 
 In particular, the PostgreSQL TCP/IP port (5444 for EDB Postgres Advanced
 Server, 5432 for EDB Postgres Extended and community PostgreSQL) must be open
-to all machines in the cluster. If you plan to deploy PGD Proxy, its port must be
-open to any applications that will connect to the cluster. Port 6432 is typically
-used for PGD Proxy.
+to all machines in the cluster. The PGD Connection Manager must also be 
+accessible to all nodes in the cluster. By default, the Connection Manager uses port 6432 (or 6444 for EDB Postgres Advanced Server).
 
 ## Worked example
 
-For this example, three hosts with Red Hat Enterprise Linux 9 were provisioned:
+For this serie of worked examples, three hosts with Red Hat Enterprise Linux 9 were provisioned:
 
-* host-one
-* host-two
-* host-three
+* host-1
+* host-2
+* host-3
 
-Each is configured with an admin user named admin.
+These hosts were configured in the cloud. As such, each host has both a public and private IP address. We will use the private IP addresses for the cluster.
 
-These hosts were configured in the cloud. As such, each host has both a public and private IP address.
+The private IP addresses are:
+* host-1: 192.168.254.166
+* host-2: 192.168.254.247
+* host-3: 192.168.254.135
 
- Name | Public IP | Private IP 
-------|-----------|----------------------
- host-one | 172.24.117.204 | 192.168.254.166 
- host-two | 172.24.113.247 | 192.168.254.247
- host-three | 172.24.117.23 | 192.168.254.135
 
 For the example cluster, `/etc/hosts` was also edited to use those private IP addresses:
 
-```
-192.168.254.166 host-one
-192.168.254.247 host-two
-192.168.254.135 host-three
+```text
+192.168.254.166 host-1
+192.168.254.247 host-2
+192.168.254.135 host-3
 ```