From 05a91c3e65a06283f91d959bbbb1adc68bae4f01 Mon Sep 17 00:00:00 2001
From: Betsy Gitelman <betsy.gitelman@enterprisedb.com>
Date: Wed, 19 Jun 2024 13:42:56 -0400
Subject: [PATCH 1/6] Re-edit of PGD - third set of edits

---
 .../deploy-config/deploy-biganimal/index.mdx  |  8 +--
 .../deploy-config/deploy-kubernetes/index.mdx |  2 +-
 .../deploy-tpa/deploying/01-configuring.mdx   |  9 ++-
 .../deploy-tpa/deploying/02-deploying.mdx     |  4 +-
 .../deploy-tpa/deploying/index.mdx            |  2 +-
 .../pgd/5/deploy-config/deploy-tpa/index.mdx  | 10 +--
 .../docs/pgd/5/deploy-config/index.mdx        |  8 +--
 .../docs/pgd/5/durability/administering.mdx   |  5 +-
 product_docs/docs/pgd/5/durability/camo.mdx   | 68 ++++++++++---------
 9 files changed, 60 insertions(+), 56 deletions(-)

diff --git a/product_docs/docs/pgd/5/deploy-config/deploy-biganimal/index.mdx b/product_docs/docs/pgd/5/deploy-config/deploy-biganimal/index.mdx
index 97810ab124e..97e4f2cc02a 100644
--- a/product_docs/docs/pgd/5/deploy-config/deploy-biganimal/index.mdx
+++ b/product_docs/docs/pgd/5/deploy-config/deploy-biganimal/index.mdx
@@ -11,8 +11,8 @@ EDB BigAnimal is a fully managed database-as-a-service with built-in Oracle comp
 This section covers how to work with EDB Postgres Distributed when deployed on BigAnimal. 
 
 * [Creating a distributed high-availability cluster](/biganimal/latest/getting_started/creating_a_cluster/creating_a_dha_cluster/) in the BigAnimal documentation works through the steps needed to:
-  * Prepare your cloud environment for a distributed high-availability cluster
-  * Sign in to BigAnimal
+  * Prepare your cloud environment for a distributed high-availability cluster.
+  * Sign in to BigAnimal.
   * Create a distributed high-availability cluster, including:
-    * Creating and configuring a data group
-    * Optionally creating and configuring a second data group in a different region
+    * Creating and configuring a data group.
+    * Optionally creating and configuring a second data group in a different region.
diff --git a/product_docs/docs/pgd/5/deploy-config/deploy-kubernetes/index.mdx b/product_docs/docs/pgd/5/deploy-config/deploy-kubernetes/index.mdx
index 6827efd747b..4cdb49317db 100644
--- a/product_docs/docs/pgd/5/deploy-config/deploy-kubernetes/index.mdx
+++ b/product_docs/docs/pgd/5/deploy-config/deploy-kubernetes/index.mdx
@@ -10,7 +10,7 @@ EDB Postgres Distributed for Kubernetes is a Kubernetes operator designed, devel
 
 This section covers how to deploy and configure EDB Postgres Distributed using the Kubernetes operator. 
 
-* A [Quickstart](/postgres_distributed_for_kubernetes/latest/quickstart) in the PGD for Kubernetes documentation works through the steps needed to:
+* [Quick start](/postgres_distributed_for_kubernetes/latest/quickstart) in the PGD for Kubernetes documentation works through the steps needed to:
   * Create a Kind/Minikube cluster.
   * Install Helm and the Helm chart for PGD for Kubernetes.
   * Create a simple configuration file for a PGD cluster.
diff --git a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/01-configuring.mdx b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/01-configuring.mdx
index 688e2ad8662..bedd73aec82 100644
--- a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/01-configuring.mdx
+++ b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/01-configuring.mdx
@@ -23,9 +23,9 @@ tpaexec configure <cluster_dir> --architecture <architecture_name> [options]
 | `--redwood` or `--no-redwood` | Required when `--edb-postgres-advanced` flag is present. Specifies whether Oracle database compatibility features are desired. |
 | `--location-names l1 l2 l3` | Required. Specifies the names of the locations to deploy PGD to. |
 | `--data-nodes-per-location N` | Specifies the number of data nodes per location. Default is 3. |
-| `--add-witness-node-per-location` | For an even number of data nodes per location, adds witness nodes to allow for local consensus. Enabled by default for 2 data node locations. |
-| `--add-proxy-nodes-per-location` | Whether to separate PGD proxies from data nodes and how many to configure. By default one proxy is configured and cohosted for each data node. |
-| `--pgd-proxy-routing global\|local` | Whether PGD Proxy routing is handled on a global or local (per-location) basis. |
+| `--add-witness-node-per-location` | For an even number of data nodes per location, adds witness nodes to allow for local consensus. Enabled by default for 2-data-node locations. |
+| `--add-proxy-nodes-per-location` | Specifies whether to separate PGD proxies from data nodes and how many to configure. By default one proxy is configured and cohosted for each data node. |
+| `--pgd-proxy-routing global\|local` | Specifies whether PGD Proxy routing is handled on a global or local (per-location) basis. |
 | `--add-witness-only-location loc` | Designates one of the cluster locations as witness-only (no data nodes are present in that location). |
 | `--enable-camo` | Sets up a CAMO pair in each location. Works only with 2 data nodes per location. |
 
@@ -48,7 +48,7 @@ The first argument must be the cluster directory, for example, `speedy` or `~/cl
 
 The command creates a directory named `~/clusters/speedy` and generates a configuration file named `config.yml` that follows the layout of the PGD-Always-ON architecture. You can use the `tpaexec configure --architecture PGD-Always-ON --help` command to see the values that are supported for the configuration options in this architecture. 
 
-In the example, the options select: 
+In the example, the options select:
 
 -  An AWS deployment (`--platform aws`) 
 -  EDB Postgres Advanced Server, version 16 and Oracle compatibility (`--edb-postgres-advanced 16` and `--redwood`) 
@@ -135,4 +135,3 @@ Specify `--hostnames-pattern`  to restrict hostnames to those matching the egrep
 By default, `tpaexec configure` uses the names first, second, and so on for any locations used by the selected architecture.
 
 Specify `--location-names` to provide more meaningful names for each location.
-
diff --git a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx
index 1d727ba8051..b9a6e03def2 100644
--- a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx
+++ b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx
@@ -16,7 +16,7 @@ The `tpaexec provision` command creates instances and other resources required b
 
 For example, given AWS access with the necessary privileges, TPA provisions EC2 instances, VPCs, subnets, routing tables, internet gateways, security groups, EBS volumes, elastic IPs, and so on.
 
-You can also provision existing servers by selecting the `bare` platform and providing connection details. Whether these are bare metal servers or those provisioned separately on a cloud platform, they can be used as if they were created by TPA.
+You can also provision existing servers by selecting the `bare` platform and providing connection details. Whether these are bare metal servers or those provisioned separately on a cloud platform, you can use them as if they were created by TPA.
 
 You aren't restricted to a single platform. You can spread your cluster out across some AWS instances in multiple regions and some on-premises servers or servers in other data centres, as needed.
 
@@ -25,6 +25,8 @@ At the end of the provisioning stage, you will have the required number of insta
 ## Deploy
 The `tpaexec deploy` command installs and configures Postgres and other software on the provisioned servers. TPA can create the servers, but it doesn't matter who created them so long as SSH and sudo access are available. This includes setting up replication, backups, and so on.
 
+<!-- What is "this">
+
 At the end of the deployment stage, EDB Postgres Distributed is up and running.
 
 ## Test
diff --git a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/index.mdx b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/index.mdx
index 9a15b43292a..31738207df9 100644
--- a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/index.mdx
+++ b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/index.mdx
@@ -37,4 +37,4 @@ At the highest level, using TPA to deploy PGD involves the following steps:
 
 &nbsp;&nbsp;&nbsp;1: [Use TPA to create a configuration](01-configuring) for your PGD cluster.
 
-&nbsp;&nbsp;&nbsp;2: [Provision, Deploy and Test](02-deploying) your PGD cluster.
+&nbsp;&nbsp;&nbsp;2: [Provision, deploy, and test](02-deploying) your PGD cluster.
diff --git a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/index.mdx b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/index.mdx
index 70bbf1bb7b1..9d60131fc06 100644
--- a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/index.mdx
+++ b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/index.mdx
@@ -17,13 +17,13 @@ both self-hosted and in the cloud (with AWS EC2).
 
     If you want to run on your own Linux systems or VMs, you can use also use TPA to [deploy EDB Postgres Distributed directly to your own Linux hosts](/pgd/latest/quickstart/quick_start_linux) 
 
-This section of the manual covers how to use TPA to deploy and administer EDB Postgres Distributed. 
+This section covers how to use TPA to deploy and administer EDB Postgres Distributed. 
 
 * [Deploying with TPA](deploying) works through the steps needed to:
-  * Installing TPA
-  * Using TPA to create a configuration
-  * Deploying the configuration with TPA
+  * Install TPA.
+  * Use TPA to create a configuration.
+  * Deploy the configuration with TPA.
 
-The installing section provides an example cluster which will be used in future examples.
+The installing section provides an example cluster that will be used in future examples.
 
 You can also [perform a rolling major version upgrade](../../upgrades/upgrading_major_rolling) with PGD administered by TPA.
diff --git a/product_docs/docs/pgd/5/deploy-config/index.mdx b/product_docs/docs/pgd/5/deploy-config/index.mdx
index 89b5a412715..c2b825eb549 100644
--- a/product_docs/docs/pgd/5/deploy-config/index.mdx
+++ b/product_docs/docs/pgd/5/deploy-config/index.mdx
@@ -13,13 +13,13 @@ This section covers how to deploy EDB Postgres Distributed and how to configure
 
 There are four main ways to deploy PGD:
 
-* [Manual deployment and administration](deploy-manual): How to manually deploy and configure EDB Postgres Distributed on a set of servers. 
+* [Manual deployment and administration](deploy-manual) describes how to manually deploy and configure EDB Postgres Distributed on a set of servers.
 
 
-* [Trusted Postgres Architect (TPA)](deploy-tpa): How to use TPA to deploy and configure EDB Postgres Distributed to a Docker environment, Linux hosts, or AWS.
+* [Trusted Postgres Architect (TPA)](deploy-tpa) describes how to use TPA to deploy and configure EDB Postgres Distributed to a Docker environment, Linux hosts, or AWS.
 
 
-* [EDB Postgres Distributed for Kubernetes](deploy-kubernetes): How to deploy and configure EDB Postgres Distributed to a Kubernetes environment.
+* [EDB Postgres Distributed for Kubernetes](deploy-kubernetes) describes how to deploy and configure EDB Postgres Distributed to a Kubernetes environment.
 
 
-* [EDB BigAnimal](deploy-biganimal): How to deploy and configure EDB Postgres Distributed on the EDB BigAnimal service.
+* [EDB BigAnimal](deploy-biganimal) describes how to deploy and configure EDB Postgres Distributed on the EDB BigAnimal service.
diff --git a/product_docs/docs/pgd/5/durability/administering.mdx b/product_docs/docs/pgd/5/durability/administering.mdx
index 6e5b7a0ac64..946e996cac6 100644
--- a/product_docs/docs/pgd/5/durability/administering.mdx
+++ b/product_docs/docs/pgd/5/durability/administering.mdx
@@ -3,8 +3,8 @@ title: Administering
 navTitle: Administering
 ---
 
-When running a PGD cluster with Group Commit, there are some things you need to
-be aware of when administering the system, such as how to safely shut down and 
+When running a PGD cluster with Group Commit, you need to
+be aware of some things when administering the system, such as how to safely shut down and 
 restart nodes.
 
 ## Planned shutdown and restarts
@@ -19,4 +19,3 @@ lead to loss of data, as if both nodes failed.
 To ensure the apply queue gets flushed to disk, use either
 [`smart` or `fast` shutdown](https://www.postgresql.org/docs/current/server-shutdown.html) for maintenance tasks. This approach maintains the
 required synchronization level and prevents loss of data.
-
diff --git a/product_docs/docs/pgd/5/durability/camo.mdx b/product_docs/docs/pgd/5/durability/camo.mdx
index 4db881b9d8a..25ff4183102 100644
--- a/product_docs/docs/pgd/5/durability/camo.mdx
+++ b/product_docs/docs/pgd/5/durability/camo.mdx
@@ -5,7 +5,7 @@ redirects:
   - /pgd/latest/bdr/camo/
 ---
 
-Commit Scope Kind: `CAMO`
+Commit scope kind: `CAMO`
 
 ## Overview
 
@@ -47,16 +47,16 @@ Configuration of CAMO happens through [commit scopes](commit-scopes).
 
 ## Confirmation
 
-   Confirmation&nbsp;Level    | CAMO Handling
+   Confirmation&nbsp;Level    | CAMO handling
 -------------------------|-------------------------------
- `received`              | Not applicable, only uses the default `VISIBLE`.
- `replicated`            | Not applicable, only uses the default `VISIBLE`.
- `durable`               | Not applicable, only uses the default `VISIBLE`.
+ `received`              | Not applicable, only uses the default, `VISIBLE`.
+ `replicated`            | Not applicable, only uses the default, `VISIBLE`.
+ `durable`               | Not applicable, only uses the default, `VISIBLE`.
  `visible` (default)     | Confirms the transaction after all of its changes are flushed to disk and it's visible to concurrent transactions.
 
 ## Limitations
 
-See the CAMO section of the [Limitations](limitations#camo) section.
+See the CAMO section of [Limitations](limitations#camo).
 
 
 ## Failure scenarios
@@ -79,7 +79,9 @@ 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 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 `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_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.
+
+<!-- Sentence fragment, this what? >
 
 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
 the CAMO partner further delays the switch back to CAMO protected mode.
@@ -91,7 +93,7 @@ Consider the choice of whether to allow asynchronous mode in view of the archite
 
 ### Example
 
-This example considers a setup with two PGD nodes that are the CAMO partner of each other.
+This example considers a setup with two PGD nodes that are the CAMO partner of each other:
 
 ```sql
 -- create a CAMO commit scope for a group over
@@ -131,34 +133,34 @@ CAMO relies on a retry loop and specific error handling on the client side. Ther
 
 The application must store the global transaction identifier only for the purpose of verifying the transaction status in case of disconnection during `COMMIT`. In particular, the application doesn't need another persistence layer. If the application fails, it needs only the information in the database to restart.
 
-To illustrate this, we have an example of a retry loop in a CAMO-aware client application, written in a C-like pseudo-code. It expects two DSNs `origin_dsn` and `partner_dsn` providing connection information. These usually are the same DSNs as used for the initial call to `bdr.create_node` and can be looked up in `bdr.node_summary`, column `interface_connstr`.
+To illustrate this, this example shows a retry loop in a CAMO-aware client application, written in a C-like pseudo-code. It expects two DSNs, `origin_dsn` and `partner_dsn`, providing connection information. These usually are the same DSNs as used for the initial call to `bdr.create_node` and can be looked up in `bdr.node_summary`, column `interface_connstr`.
 
 ```
 PGconn *conn = PQconnectdb(origin_dsn);
 ```
 
-The process starts connecting to the origin node. We now enter our loop:
+The process starts connecting to the origin node. Now enter the loop:
 
 ```
 loop {
     PQexec(conn, "BEGIN");
 ```
 
-We start our transaction and begin populating it with changes:
+Next, start the transaction and begin populating it with changes:
 
 ```
     PQexec(conn, "INSERT INTO ...");
     ...
 ```
 
-Once we are done, we need to make a record of the local node id and the transaction id. Both are available as parameters.
+Once you're done, you need to make a record of the local node id and the transaction id. Both are available as parameters.
 
 ```
     node_id = PQparameterStatus(conn, "bdr.local_node_id");
     xid = PQparameterStatus(conn, "transaction_id");
 ```
 
-We are now ready to try and commit.
+Now it's ready to try to commit.
 
 ```
     PQexec(conn, "COMMIT");
@@ -166,14 +168,14 @@ We are now ready to try and commit.
         return SUCCESS;
 ```
 
-If the result is `PGRES_COMMAND_OK`, we are good and ready to move on. But if it isn't, we need to use CAMO to track the transaction to completion. The first question we need to ask is was the connection bad?
+If the result is `PGRES_COMMAND_OK`, that's good, and you can move on. But if it isn't, you need to use CAMO to track the transaction to completion. The first question to ask is, "Was the connection bad?"
 
 ```
     else if (PQstatus(res) == CONNECTION_BAD)
     {
 ```
 
-If it was a bad connection, then we can check on the CAMO partner node to see if the transaction made it there.
+If it was a bad connection, then you can check on the CAMO partner node to see if the transaction made it there.
 
 ```
         conn = PQconnectdb(partner_dsn);
@@ -181,9 +183,11 @@ If it was a bad connection, then we can check on the CAMO partner node to see if
             panic();
 ```
 
-If we can't connect to the partner node, there's not a lot we can do. So we should panic, or take similar actions.
+If you can't connect to the partner node, there's not a lot you can do. So we should panic, or take similar actions.
+
+<!-- surely not >
 
-But if we can connect, we can use [`bdr.logical_transaction_status()`](/pgd/latest/reference/functions#bdrlogical_transaction_status) to find out how the transaction did. We recorded the required values, node_id and xid - the transaction id, just before we committed the transaction.
+But if you can connect, you can use [`bdr.logical_transaction_status()`](/pgd/latest/reference/functions#bdrlogical_transaction_status) to find out how the transaction did. The code recorded the required values, node_id and xid (the transaction id), just before committing the transaction.
 
 ```
         sql = "SELECT bdr.logical_transaction_status($node_id, $xid)";
@@ -195,7 +199,7 @@ But if we can connect, we can use [`bdr.logical_transaction_status()`](/pgd/late
     }
 ```
 
-If the transaction reports it has been committed, then we can call this transaction a success. No more action is required. If, on the other hand, it does not report it has been committed, we should continue in the loop so the transaction can be retried on the partner node.
+If the transaction reports it's been committed, then you can call this transaction a success. No more action is required. If, on the other hand, it doesn't report it's been committed, continue in the loop so the transaction can be retried on the partner node.
 
 ```
     else
@@ -212,7 +216,7 @@ If the transaction reports it has been committed, then we can call this transact
 }
 ```
 
-If status of the transaction wasn't success or connection was bad, we check if the problem was a permanent error; if so, we should report a failure of the transaction. If not, it is still able to be retried and the code should sleep for a period of time that increases with each retry, and then retry the transaction.
+If status of the transaction wasn't success or bad connection, check if the problem was a permanent error. If so, report a failure of the transaction. If not, you can still retry it. Have the code sleep for a period of time that increases with each retry, and then retry the transaction.
 
 
 ### Working with the CAMO partner
@@ -227,13 +231,13 @@ The function [`bdr.is_camo_partner_connected()`](/pgd/latest/reference/functions
 
 To check that the CAMO partner is ready, use the function [`bdr.is_camo_partner_ready`](/pgd/latest/reference/functions#bdris_camo_partner_ready). Underneath, this triggers the switch to and from local mode.
 
-To find out more about the configured CAMO partner, use [`bdr.get_configured_camo_partner()`](/pgd/latest/reference/functions#bdrget_configured_camo_partner). This will returns the local node's CAMO partner.
+To find out more about the configured CAMO partner, use [`bdr.get_configured_camo_partner()`](/pgd/latest/reference/functions#bdrget_configured_camo_partner). This function returns the local node's CAMO partner.
 
-You can wait on the camo partner to process the queue with the function
+You can wait on the CAMO partner to process the queue with the function
 [`bdr.wait_for_camo_partner_queue()`](/pgd/latest/reference/functions#bdrwait_for_camo_partner_queue).
 This function is a wrapper of
-[`bdr.wait_for_apply_queue`](/pgd/latest/reference/functions#bdrwait_for_apply_queue),
-the difference being that
+[`bdr.wait_for_apply_queue`](/pgd/latest/reference/functions#bdrwait_for_apply_queue).
+The difference is that
 [`bdr.wait_for_camo_partner_queue()`](/pgd/latest/reference/functions#bdrwait_for_camo_partner_queue)
 defaults to querying the CAMO partner node. It returns an error if the local
 node isn't part of a CAMO pair.
@@ -243,9 +247,9 @@ failed, the application must use the function
 [`bdr.logical_transaction_status`](/pgd/latest/reference/functions#bdrlogical_transaction_status).
 
 You pass this function the the node_id and transaction_id of the transaction you want to check
-on. With CAMO used in pair mode, you can only use this function on a node that's part of a CAMO pair. Along with Eager Replication, you can use it on all nodes.
+on. With CAMO used in pair mode, you can use this function only on a node that's part of a CAMO pair. Along with Eager Replication, you can use it on all nodes.
 
-In all cases, you must call the function within 15 minutes after the commit was issued. The CAMO partner must regularly purge such meta-information and therefore can't provide correct answers for older transactions.
+In all cases, you must call the function within 15 minutes after of issuing the commit. The CAMO partner must regularly purge such meta-information and therefore can't provide correct answers for older transactions.
 
 Before querying the status of a transaction, this function waits for the receive queue to be consumed and fully applied. This mechanism prevents early negative answers for transactions that were received but not yet applied.
 
@@ -256,25 +260,25 @@ forced to roll back.
 
 ### Connection pools and proxies
 
-Consider the effect of connection pools and proxies when designing a CAMO cluster. A proxy might freely distribute transactions to all nodes in the commit group, that is, to both nodes of a CAMO pair or to all PGD nodes in case of Eager All-Node Replication).
+Consider the effect of connection pools and proxies when designing a CAMO cluster. A proxy might freely distribute transactions to all nodes in the commit group, that is, to both nodes of a CAMO pair or to all PGD nodes in case of Eager All-Node Replication.
 
-Take care to ensure that the application fetches the proper node id. When using session pooling, the client remains connected to the same node, so the node id remains constant for the lifetime of the client session. However, with finer-grained transaction pooling, the client needs to fetch the node id for every transaction (as in the example that follows.
+Take care to ensure that the application fetches the proper node id. When using session pooling, the client remains connected to the same node, so the node id remains constant for the lifetime of the client session. However, with finer-grained transaction pooling, the client needs to fetch the node id for every transaction, as in the example that follows.
 
-A client that isn't directly connected to the PGD nodes might not even notice a failover or switchover. But it can always use the `bdr.local_node_id` parameter to determine which node it's currently connected to. In the crucial situation of a disconnect during COMMIT, the proxy must properly forward that disconnect as an error to the client applying the CAMO protocol.
+A client that isn't directly connected to the PGD nodes might not even notice a failover or switchover. But it can always use the `bdr.local_node_id` parameter to determine the node it's currently connected to. In the crucial situation of a disconnect during COMMIT, the proxy must properly forward that disconnect as an error to the client applying the CAMO protocol.
 
 For CAMO in `received` mode, a proxy that potentially switches between the CAMO pairs must use the `bdr.wait_for_camo_partner_queue` function to prevent stale reads.
 
 ## CAMO limitations
 
-CAMO limitations are covered on the [Durability limitations](limitations/#camo) page.
+CAMO limitations are covered in [Durability limitations](limitations/#camo).
 
 ## Performance implications
 
-CAMO extends the Postgres replication protocol by adding a message roundtrip at commit. Applications have a higher
-commit latency than with asynchronous replication, mostly determined by the roundtrip time between involved nodes. Increasing the number of concurrent sessions can help to increase parallelism to obtain reasonable transaction throughput.
+CAMO extends the Postgres replication protocol by adding a message round trip at commit. Applications have a higher
+commit latency than with asynchronous replication, mostly determined by the round-trip time between involved nodes. Increasing the number of concurrent sessions can help to increase parallelism to obtain reasonable transaction throughput.
 
 The CAMO partner confirming transactions must store transaction states. Compared to non-CAMO operation, this might require an added seek for each transaction applied from the origin.
 
 ## Client application testing
 
-Proper use of CAMO on the client side isn't trivial. We strongly recommend testing the application behavior with the PGD cluster against failure scenarios such as node crashes or network outages.
+Proper use of CAMO on the client side isn't trivial. We strongly recommend testing the application behavior with the PGD cluster against failure scenarios, such as node crashes or network outages.

From 2d1ea00e4282fefdae9f496900133d2afc0b38c5 Mon Sep 17 00:00:00 2001
From: Betsy Gitelman <betsy.gitelman@enterprisedb.com>
Date: Wed, 19 Jun 2024 13:48:50 -0400
Subject: [PATCH 2/6] Apply suggestions from code review

---
 .../pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx   | 1 -
 product_docs/docs/pgd/5/durability/camo.mdx                     | 2 --
 2 files changed, 3 deletions(-)

diff --git a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx
index b9a6e03def2..f99dbf30762 100644
--- a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx
+++ b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx
@@ -25,7 +25,6 @@ At the end of the provisioning stage, you will have the required number of insta
 ## Deploy
 The `tpaexec deploy` command installs and configures Postgres and other software on the provisioned servers. TPA can create the servers, but it doesn't matter who created them so long as SSH and sudo access are available. This includes setting up replication, backups, and so on.
 
-<!-- What is "this">
 
 At the end of the deployment stage, EDB Postgres Distributed is up and running.
 
diff --git a/product_docs/docs/pgd/5/durability/camo.mdx b/product_docs/docs/pgd/5/durability/camo.mdx
index 25ff4183102..b53c96e0fee 100644
--- a/product_docs/docs/pgd/5/durability/camo.mdx
+++ b/product_docs/docs/pgd/5/durability/camo.mdx
@@ -81,7 +81,6 @@ For a CAMO partner to switch to ready, it needs to be connected, and the estimat
 
 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.
 
-<!-- Sentence fragment, this what? >
 
 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
 the CAMO partner further delays the switch back to CAMO protected mode.
@@ -185,7 +184,6 @@ If it was a bad connection, then you can check on the CAMO partner node to see i
 
 If you can't connect to the partner node, there's not a lot you can do. So we should panic, or take similar actions.
 
-<!-- surely not >
 
 But if you can connect, you can use [`bdr.logical_transaction_status()`](/pgd/latest/reference/functions#bdrlogical_transaction_status) to find out how the transaction did. The code recorded the required values, node_id and xid (the transaction id), just before committing the transaction.
 

From 2aa593580c3f5320568c7d3c3039dff2dc050997 Mon Sep 17 00:00:00 2001
From: Betsy Gitelman <betsy.gitelman@enterprisedb.com>
Date: Tue, 25 Jun 2024 15:21:42 -0400
Subject: [PATCH 3/6] Update product_docs/docs/pgd/5/durability/camo.mdx

---
 product_docs/docs/pgd/5/durability/camo.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/product_docs/docs/pgd/5/durability/camo.mdx b/product_docs/docs/pgd/5/durability/camo.mdx
index b53c96e0fee..9526e99b36d 100644
--- a/product_docs/docs/pgd/5/durability/camo.mdx
+++ b/product_docs/docs/pgd/5/durability/camo.mdx
@@ -182,7 +182,7 @@ If it was a bad connection, then you can check on the CAMO partner node to see i
             panic();
 ```
 
-If you can't connect to the partner node, there's not a lot you can do. So we should panic, or take similar actions.
+If you can't connect to the partner node, there's not a lot you can do. In this case, panic, or take similar actions.
 
 
 But if you can connect, you can use [`bdr.logical_transaction_status()`](/pgd/latest/reference/functions#bdrlogical_transaction_status) to find out how the transaction did. The code recorded the required values, node_id and xid (the transaction id), just before committing the transaction.

From 3cfaff588bebaedf80c03b8b79f78cb191f0a9f6 Mon Sep 17 00:00:00 2001
From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com>
Date: Wed, 26 Jun 2024 11:46:50 +0100
Subject: [PATCH 4/6] Update 02-deploying.mdx

---
 .../pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx
index f99dbf30762..51a0136d452 100644
--- a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx
+++ b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/deploying/02-deploying.mdx
@@ -23,7 +23,7 @@ You aren't restricted to a single platform. You can spread your cluster out acro
 At the end of the provisioning stage, you will have the required number of instances with the basic operating system installed, which TPA can access using SSH (with sudo to root).
 
 ## Deploy
-The `tpaexec deploy` command installs and configures Postgres and other software on the provisioned servers. TPA can create the servers, but it doesn't matter who created them so long as SSH and sudo access are available. This includes setting up replication, backups, and so on.
+The `tpaexec deploy` command installs and configures Postgres and other software on the provisioned servers. This includes setting up replication, backups, and so on. TPA can create the servers, but it doesn't matter who created them so long as SSH and sudo access are available. 
 
 
 At the end of the deployment stage, EDB Postgres Distributed is up and running.
@@ -33,4 +33,4 @@ The `tpaexec test` command executes various architecture and platform-specific t
 
 At the end of the testing stage, you have a fully functioning cluster.
 
-For more information, see [Trusted Postgres Architect](/tpa/latest/).
\ No newline at end of file
+For more information, see [Trusted Postgres Architect](/tpa/latest/).

From 9aa210cd8325ad315bc3a58af495e7b2199053b8 Mon Sep 17 00:00:00 2001
From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com>
Date: Wed, 26 Jun 2024 11:48:09 +0100
Subject: [PATCH 5/6] Fixed links

---
 product_docs/docs/pgd/5/deploy-config/deploy-tpa/index.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/index.mdx b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/index.mdx
index 9d60131fc06..e69081153d9 100644
--- a/product_docs/docs/pgd/5/deploy-config/deploy-tpa/index.mdx
+++ b/product_docs/docs/pgd/5/deploy-config/deploy-tpa/index.mdx
@@ -11,11 +11,11 @@ both self-hosted and in the cloud (with AWS EC2).
  
 !!! Note Get started with TPA and PGD quickly 
 
-    If you want to experiment with a local deployment as quickly as possible, you can [deploying an EDB Postgres Distributed example cluster on Docker](/pgd/latest/quickstart/quick_start_docker) to configure, provision, and deploy a PGD 5 Always-on cluster on Docker.
+    If you want to experiment with a local deployment as quickly as possible, you can [deploying an EDB Postgres Distributed example cluster on Docker](../../quickstart/quick_start_docker) to configure, provision, and deploy a PGD 5 Always-on cluster on Docker.
     
-    If deploying to the cloud is your aim, you can [deploying an EDB Postgres Distributed example cluster on AWS](/pgd/latest/quickstart/quick_start_aws) to get a PGD 5 cluster on your own Amazon account.
+    If deploying to the cloud is your aim, you can [deploying an EDB Postgres Distributed example cluster on AWS](../../quickstart/quick_start_aws) to get a PGD 5 cluster on your own Amazon account.
 
-    If you want to run on your own Linux systems or VMs, you can use also use TPA to [deploy EDB Postgres Distributed directly to your own Linux hosts](/pgd/latest/quickstart/quick_start_linux) 
+    If you want to run on your own Linux systems or VMs, you can use also use TPA to [deploy EDB Postgres Distributed directly to your own Linux hosts](../../quickstart/quick_start_linux) 
 
 This section covers how to use TPA to deploy and administer EDB Postgres Distributed. 
 

From cb264f77c8f320fcc429b17148f96c88161c536e Mon Sep 17 00:00:00 2001
From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com>
Date: Wed, 26 Jun 2024 12:03:34 +0100
Subject: [PATCH 6/6] Update product_docs/docs/pgd/5/durability/camo.mdx

---
 product_docs/docs/pgd/5/durability/camo.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/product_docs/docs/pgd/5/durability/camo.mdx b/product_docs/docs/pgd/5/durability/camo.mdx
index 9526e99b36d..226ff31810b 100644
--- a/product_docs/docs/pgd/5/durability/camo.mdx
+++ b/product_docs/docs/pgd/5/durability/camo.mdx
@@ -272,7 +272,7 @@ CAMO limitations are covered in [Durability limitations](limitations/#camo).
 
 ## Performance implications
 
-CAMO extends the Postgres replication protocol by adding a message round trip at commit. Applications have a higher
+CAMO extends the Postgres replication protocol by adding a message roundtrip at commit. Applications have a higher
 commit latency than with asynchronous replication, mostly determined by the round-trip time between involved nodes. Increasing the number of concurrent sessions can help to increase parallelism to obtain reasonable transaction throughput.
 
 The CAMO partner confirming transactions must store transaction states. Compared to non-CAMO operation, this might require an added seek for each transaction applied from the origin.