Additional edits to first set of PGD edits

product_docs/docs/pgd/5/ddl/ddl-managing-with-pgd-replication.mdx

@@ -8,8 +8,8 @@ navTitle: Managing with replication
 Minimizing the impact of DDL is good operational advice for any database. These points become even more
 important with PGD:
 
--   To minimize the impact of DDL, make transactions performing DDL short,
-    don't combine them with lots of row changes, and avoid long-running 
+-   To minimize the impact of DDL, make transactions performing DDL short.
+    Don't combine them with lots of row changes, and avoid long-running 
     foreign key or other constraint rechecks.
 
 -   For `ALTER TABLE`, use `ADD CONSTRAINT NOT VALID` followed by another
@@ -37,7 +37,7 @@ INDEX CONCURRENTLY`, noting that DDL replication must be disabled for the whole
 session because `CREATE INDEX CONCURRENTLY` is a multi-transaction command.
 Avoid `CREATE INDEX` on production systems
 since it prevents writes while it executes.
-`REINDEX` is replicated in versions up to 3.6 but not with PGD 3.7 or later.
+`REINDEX` is replicated in versions 3.6 and earlier but not with PGD 3.7 or later.
 Avoid using `REINDEX` because of the AccessExclusiveLocks it holds.
 
 Instead, use `REINDEX CONCURRENTLY` (or `reindexdb --concurrently`),
@@ -107,7 +107,7 @@ by turning [`bdr.ddl_replication`](/pgd/latest/reference/pgd-settings#bdrddl_rep
 PGD prevents some DDL statements from running when it's active on a
 database. This protects the consistency of the system by disallowing
 statements that can't be replicated correctly or for which replication
-isn't yet supported. 
+isn't yet supported.
 
 If a statement isn't permitted under PGD, you can often find
 another way to do the same thing. For example, you can't do an `ALTER TABLE`,

product_docs/docs/pgd/5/ddl/ddl-overview.mdx

@@ -32,7 +32,7 @@ comes to DDL replication. Treating it the same is the most
 common issue with PGD.
 
 The main difference from table replication is that DDL replication doesn't
-replicate the result of the DDL but the statement itself. This works
+replicate the result of the DDL. Instead, it replicates the statement. This works
 very well in most cases, although it introduces the requirement that the DDL
 must execute similarly on all nodes. A more subtle point is that the DDL
 must be immutable with respect to all datatype-specific parameter settings,
@@ -59,10 +59,10 @@ PGD offers three levels of protection against those problems:
 `ddl_locking = 'all'` is the strictest option and is best when DDL might execute
 from any node concurrently and you want to ensure correctness. This is the default.
 
-`ddl_locking = 'dml'` is an option that is only safe when you execute
-DDL from one node at any time. You should only use this setting 
-if you can completely control where DDL is executed.  Executing DDL from a single node
-it ensures that there are no inter-node conflicts. Intra-node conflicts are already
+`ddl_locking = 'dml'` is an option that is safe only when you execute
+DDL from one node at any time. Use this setting only
+if you can completely control where DDL is executed. Executing DDL from a single node
+ensures that there are no inter-node conflicts. Intra-node conflicts are already
 handled by PostgreSQL.
 
 `ddl_locking = 'off'` is the least strict option and is dangerous in general use.
@@ -71,9 +71,7 @@ it a useful option when creating a new and empty database schema.
 
 These options can be set only by the bdr_superuser, by the superuser, or in the `postgres.conf` configuration file.
 
-
 When using the [`bdr.replicate_ddl_command`](/pgd/latest/reference/functions#bdrreplicate_ddl_command), you can set this
 parameter directly with the third argument, using the specified
 [`bdr.ddl_locking`](/pgd/latest/reference/pgd-settings#bdrddl_locking) setting only for the DDL commands passed to that
 function.
-