Merge pull request #5983 from EnterpriseDB/docs/rpgd_reedit_last

Reedit of PGD - final group

Author: djw-m

product_docs/docs/pgd/5/monitoring/sql.mdx

@@ -534,7 +534,7 @@ bdrdb=# SELECT * FROM bdr.monitor_group_versions();
 ## Monitoring Raft consensus
 
 Raft consensus must be working cluster-wide at all times. The impact
-of running a EDB Postgres Distributed cluster without Raft consensus working might be as
+of running an EDB Postgres Distributed cluster without Raft consensus working might be as
 follows:
 
 -   The replication of PGD data changes might still work correctly.

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

@@ -3,12 +3,12 @@ title: Joining a heterogeneous cluster
 ---
 
 
-A PGD 4.0 node can join a EDB Postgres Distributed cluster running 3.7.x at a specific
+A PGD 4.0 node can join an EDB Postgres Distributed cluster running 3.7.x at a specific
 minimum maintenance release (such as 3.7.6) or a mix of 3.7 and 4.0 nodes.
 This procedure is useful when you want to upgrade not just the PGD
 major version but also the underlying PostgreSQL major
 version. You can achieve this by joining a 3.7 node running on
-PostgreSQL 12 or 13 to a EDB Postgres Distributed cluster running 3.6.x on
+PostgreSQL 12 or 13 to an EDB Postgres Distributed cluster running 3.6.x on
 PostgreSQL 11. The new node can also
 run on the same PostgreSQL major release as all of the nodes in the
 existing cluster.

product_docs/docs/pgd/5/testingandtuning.mdx

@@ -7,7 +7,7 @@ description: Learn how to test and tune EDB Postgres Distributed clusters.
 You can test PGD applications using the following approaches:
 
 -   [Trusted Postgres Architect](#trusted-postgres-architect)
--   [pgd_bench with CAMO/Failover options](#pgd_bench)
+-   [pgd_bench with CAMO/failover options](#pgd_bench)
 
 
 ### Trusted Postgres Architect
@@ -37,7 +37,7 @@ extended in PGD 5.0 in the form of a new application: pgd_bench.
 directory. The utility is based on the PostgreSQL pgbench tool but
 supports benchmarking CAMO transactions and PGD-specific workloads.
 
-Functionality of pgd_bench is a superset of those of pgbench but
+Functionality of pgd_bench is a superset of pgbench functionality but
 requires the BDR extension to be installed to work properly.
 
 Key differences include:
@@ -46,7 +46,7 @@ Key differences include:
     pgbench scenario to prevent global lock timeouts in certain cases.
 -   `VACUUM` command in the standard scenario is executed on all nodes.
 -   pgd_bench releases are tied to the releases of the BDR extension
-    and are built against the corresponding Postgres distribution. This is
+    and are built against the corresponding Postgres distribution. This information is
     reflected in the output of the `--version` flag.
 
 The current version allows you to run failover tests while using CAMO or
@@ -60,7 +60,7 @@ mode in which pgbench should run (default: regular)
 ```
 
 -   Use `-m camo` or `-m failover` to specify the mode for pgd_bench.
-    You can use The `-m failover` specification to test failover in
+    You can use the `-m failover` specification to test failover in
     regular PGD deployments.
 
 ```
@@ -89,7 +89,7 @@ to get the status of in-flight transactions. Aborted and in-flight transactions
 are retried in CAMO mode.
 
 In failover mode, if you specify `--retry`, then in-flight transactions are
-retried. In this scenario there's no way to find the status of in-flight
+retried. In this scenario, there's no way to find the status of in-flight
 transactions.
 
 ### Notes on pgd_bench usage
@@ -126,7 +126,7 @@ Complex applications require some thought to maintain scalability.
 
 If you think you're having performance problems, develop performance tests using
 the benchmarking tools. pgd_bench allows you to write custom test scripts specific
-to your use case so you can understand the overheads of your SQL and measure the
+to your use case so you can understand the overhead of your SQL and measure the
 impact of concurrent execution.
 
 If PGD is running slow, then we suggest the following:

product_docs/docs/pgd/5/transaction-streaming.mdx

@@ -31,7 +31,7 @@ limitations:
 -   If the transaction aborts, the work (changes received by each subscriber
     and the associated storage I/O) is wasted.
 
-However, starting with version 3.7, PGD supports parallel apply, enabling multiple writer
+However, starting with version 3.7, PGD supports Parallel Apply, enabling multiple writer
 processes on each subscriber. This capability is leveraged to provide the following enhancements:
 
 -   Decoded transactions can be streamed directly to a writer on the subscriber.
@@ -41,7 +41,7 @@ processes on each subscriber. This capability is leveraged to provide the follow
 
 ### Caveats
 
--   You must enable parallel apply.
+-   You must enable Parallel Apply.
 -   Workloads consisting of many small and conflicting transactions can lead to
     frequent deadlocks between writers.
 
@@ -108,16 +108,16 @@ streaming, the subscriber requests transaction streaming.
 If the publisher can provide transaction streaming, it
 streams transactions whenever the transaction size exceeds the threshold set in
 `logical_decoding_work_mem`. The publisher usually has no control over whether
-the transactions is streamed to a file or to a writer. Except for some
+the transactions are streamed to a file or to a writer. Except for some
 situations (such as COPY), it might hint for the subscriber to stream the
 transaction to a writer (if possible).
 
 The subscriber can stream transactions received from the publisher to
 either a writer or a file. The decision is based on several factors:
 
--   If parallel apply is off (`num_writers = 1`), then it's streamed to a file.
+-   If Parallel Apply is off (`num_writers = 1`), then it's streamed to a file.
     (writer 0 is always reserved for non-streamed transactions.)
--   If parallel apply is on but all writers are already busy handling streamed
+-   If Parallel Apply is on but all writers are already busy handling streamed
     transactions, then the new transaction is streamed to a file. See
     [Monitoring PGD writers](monitoring/sql#monitoring-pgd-writers) to check PGD
     writer status.

product_docs/docs/pgd/5/twophase.mdx

@@ -8,7 +8,7 @@ redirects:
 ---
 
 !!!Note
-Two-phase commit is not available with Group Commit or CAMO. See [Durability limitations](durability/limitations).
+Two-phase commit isn't available with Group Commit or CAMO. See [Durability limitations](durability/limitations).
 !!!
 
 An application can explicitly opt to use two-phase commit with PGD. See
@@ -19,14 +19,14 @@ software components:
 
 -   An application program (AP) that defines transaction boundaries and specifies
     actions that constitute a transaction
--   Resource managers (RMs, such as databases or file-access systems) that provide
+-   Resource managers (RMs), such as databases or file-access systems, that provide
     access to shared resources
 -   A separate component called a transaction manager (TM) that assigns identifiers
     to transactions, monitors their progress, and takes responsibility for
     transaction completion and for failure recovery
 
 PGD supports explicit external 2PC using the `PREPARE TRANSACTION` and
-`COMMIT PREPARED`/`ROLLBACK PREPARED` commands. Externally, a EDB Postgres Distributed cluster
+`COMMIT PREPARED`/`ROLLBACK PREPARED` commands. Externally, an EDB Postgres Distributed cluster
 appears to be a single resource manager to the transaction manager for a
 single session.
 
@@ -44,7 +44,7 @@ or the global commit scope. Future releases might enable this combination.
 ## Use
 
 Two-phase commits with a local commit scope work exactly like standard
-PostgreSQL. Use the local commit scope and disable CAMO.
+PostgreSQL. Use the local commit scope and disable CAMO:
 
 ```sql
 BEGIN;