Merge pull request #6298 from EnterpriseDB/docs/edits_to_pgd_6210

Edits to DOCS-1076 - Documenting PGD 5.6.1 #6210
EnterpriseDB · Dec 5, 2024 · 8c0c4d7 · 8c0c4d7 · github-actions · Dec 5, 2024
2 parents 6720ef1 + 462af52
commit 8c0c4d7
Show file tree

Hide file tree

Showing 5 changed files with 22 additions and 18 deletions.
diff --git a/product_docs/docs/pgd/5.6/conflict-management/conflicts/02_types_of_conflict.mdx b/product_docs/docs/pgd/5.6/conflict-management/conflicts/02_types_of_conflict.mdx
@@ -33,13 +33,17 @@ You can effectively eliminate this type of conflict by using [global sequences](
 
 ### INSERT operations that violate UNIQUE or EXCLUDE constraints
 
-An `INSERT`/`INSERT` conflict can violate more than one `UNIQUE` constraint, of which one might be the `PRIMARY KEY`. 
-With the addition of `EXCLUDE` constraint support in PGD 5.6, an `INSERT`/`INSERT`conflict can also violate one or more `EXCLUDE` constraints. 
+An `INSERT`/`INSERT` conflict can violate more than one `UNIQUE` constraint, one of which might be the `PRIMARY KEY`. 
+With the addition of `EXCLUDE` constraint support in PGD 5.6, an `INSERT`/`INSERT`conflict can also violate one or more `EXCLUDE` constraints.
 
-If a new row violates more than one `UNIQUE` constraint and that results in a conflict against more than one other row, or a new row violates more than one `EXCLUDE` constraint or a single `EXCLUDE` constraint, either of which results in a conflict against more than one other row, then applying the replication change produces a `multiple_unique_conflicts` conflict.
+In either of the following cases, applying the replication change produces a `multiple_unique_conflicts` conflict. Both of these cases result in a conflict against more than one other row.
 
-In case of such a conflict, you must remove some rows for replication to continue. 
-Depending on the resolver setting for `multiple_unique_conflicts`, the apply process either exits with error, skips the incoming row, or deletes some of the rows. 
+- If a new row violates more than one `UNIQUE` constraint and that results in a conflict against more than one other row. 
+
+- If a new row violates more than one `EXCLUDE` constraint or a single `EXCLUDE` constraint.
+
+In case of such a conflict, for replication to continue, you must remove some rows. 
+Depending on the resolver setting for `multiple_unique_conflicts`, the apply process either exits with an error, skips the incoming row, or deletes some of the rows. 
 The deletion tries to preserve the row with the correct `PRIMARY KEY` and delete the others.
 
 !!! Warning

diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-command-handling.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-command-handling.mdx
@@ -228,7 +228,7 @@ under the following table.
 | VACUUM                           | Y                                             | N                                          | N                                                |
 
 
-## Command Notes
+## Command notes
 <div id='bdr_ddl_allowed_AlterSeqStmt'></div>
 
 ### ALTER SEQUENCE
@@ -253,11 +253,11 @@ Some variants of `ALTER TABLE` currently aren't allowed on a PGD node:
 -   `ADD COLUMN ... DEFAULT (non-immutable expression)` &mdash; This is not allowed because
     it currently results in different data on different nodes. See
     [Adding a column](ddl-workarounds/#adding-a-column) for a suggested workaround.
-    This can be overriden using `bdr.permit_unsafe_commands` if user is sure the command is
+    You can override this behavior using `bdr.permit_unsafe_commands` if you're sure the command is
     safe.
 -   `ALTER COLUMN ... SET STORAGE external` &mdash; Is rejected if the column is
     one of the columns of the replica identity for the table.
-    This can be overriden using `bdr.permit_unsafe_commands` if user is sure the command is
+    You can override this behavior using `bdr.permit_unsafe_commands` if you're sure the command is
     safe.
 -   `RENAME` &mdash; Can't rename an Autopartitioned table.
 -   `SET SCHEMA` &mdash; Can't set the schema of an Autopartitioned table.

diff --git a/product_docs/docs/pgd/5.6/index.mdx b/product_docs/docs/pgd/5.6/index.mdx
@@ -74,7 +74,7 @@ the peer nodes only after the local commit. You can configure additional levels
 
 ## Compatibility
 
-EDB Postgres Distributed 5 is compatible with PostgreSQL, EDB Postgres Extended, and EDB Postgres Advanced versions 12-17. See the [compatibility](compatibility) section for more details, including compatibility with different operating systems and architectures.
+EDB Postgres Distributed 5 is compatible with PostgreSQL, EDB Postgres Extended, and EDB Postgres Advanced versions 12-17. See [Compatibility](compatibility) for more details, including information about compatibility with different operating systems and architectures.
 For feature compatibility with compatible servers, see [Choosing a Postgres distribution](planning/choosing_server).
 
 ---
diff --git a/product_docs/docs/pgd/5.6/reference/functions.mdx b/product_docs/docs/pgd/5.6/reference/functions.mdx
@@ -314,9 +314,9 @@ If no node name is supplied (by passing NULL), the function waits until all the
 
 We recommend using this function if you are using [Optimized Topology](../nodes/subscriber_only/optimizing-so) instead of [`bdr.wait_slot_confirm_lsn`](/pgd/5.6/reference/functions#bdrwait_slot_confirm_lsn).
 
-This is because in an Optimized Topology, not all nodes have replication slots, so the function `bdr.wait_slot_confirm_lsn` might not work as expected. `bdr.wait_node_confirm_lsn` is designed to work with nodes that don't have replication slots, using alternative straegies to determine the progress of a node.
+This is because in an Optimized Topology, not all nodes have replication slots, so the function `bdr.wait_slot_confirm_lsn` might not work as expected. `bdr.wait_node_confirm_lsn` is designed to work with nodes that don't have replication slots, using alternative strategies to determine the progress of a node.
 
-If a node is currently down, isn't updating or is simply not able to be connected to, the wait will continue indefinately. To avoid this, set the statement_timeout to the maximum amount of time you are prepared to wait.
+If a node is currently down, isn't updating, or simply can't be connected to, the wait will continue indefinitely. To avoid this condition, set the statement_timeout to the maximum amount of time you are prepared to wait.
 
 #### Synopsis
 
@@ -432,7 +432,7 @@ bdr.replicate_ddl_command(ddl_cmd text,
 | Parameter | Description |
 | --------- | ----------- |
 | `ddl_cmd` | DDL command to execute. |
-| `replication_sets` | An array of replication set names to apply the `ddlcommand` to. If NULL (or the function is only passed the `ddlcommand`), this is set to the active PGD groups's default replication set. |
+| `replication_sets` | An array of replication set names to apply the `ddlcommand` to. If NULL (or the function is passed only the `ddlcommand`), this parameter is set to the active PGD groups's default replication set. |
 | `ddl_locking` | A string that sets the [`bdr.ddl_locking`](/pgd/latest/reference/pgd-settings#bdrddl_locking) value while replicating. Defaults to the GUC value for `bdr.ddl_locking` on the local system that's running `replicate_ddl_command`. |
 | `execute_locally` | A Boolean that determines whether the DDL command executes locally. Defaults to true. |
 
@@ -1006,7 +1006,7 @@ bdr.wal_sender_stats()
 
 | Column name         | Description                                                                         |
 |---------------------|-------------------------------------------------------------------------------------|
-| `pid`               | PID of the WAL sender.  (corresponds to the `pid` column of `pg_stat_replication`). |
+| `pid`               | PID of the WAL sender. (Corresponds to the `pid` column of `pg_stat_replication`). |
 | `is_using_lcr`      | Whether the WAL sender is sending LCR files.                                        |
 | `decoder_slot_name` | Name of the decoder replication slot.                                               |
 | `lcr_file_name`     | Name of the current LCR file.                                                       |
@@ -1029,7 +1029,7 @@ bdr.get_decoding_worker_stat()
 
 | Column name | Description |
 |-------------|-------------|
-| `pid` | The PID of the decoding worker (corresponds to the column `active_pid` in `pg_replication_slots`). |
+| `pid` | The PID of the decoding worker. (Corresponds to the column `active_pid` in `pg_replication_slots`.) |
 | `decoded_upto_lsn` | LSN up to which the decoding worker read transactional logs. |
 | `waiting` | Whether the decoding worker is waiting for new WAL. |
 | `waiting_for_lsn` | The LSN of the next expected WAL. |

diff --git a/product_docs/docs/pgd/5.6/reference/nodes.mdx b/product_docs/docs/pgd/5.6/reference/nodes.mdx
@@ -114,9 +114,9 @@ present but empty.
 
 ### `bdr_config`
 
-This command-line utility allows the user to examine the configuration of a PGD installation.
-It is analogous to the `pg_config` utility that comes with PostgreSQL. It can be used to assist
-in trouble-shooting and support.
+This command-line utility allows you to examine the configuration of a PGD installation.
+It is analogous to the `pg_config` utility that comes with PostgreSQL. You can use it to assist
+in troubleshooting and support.
 
 #### Synopsis
 
@@ -129,7 +129,7 @@ bdr_config [OPTION] ...
 | Option&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Description |
 | --- | --- |
 | `--all` | Show all the keys and values in the configuration. |
-| `--version` | Show only the BDR version related keys and values.  This include the full version of the BDR extension, the Postgres version and flavor it is running against and the BDRPG and BDR plugin API versions. |
+| `--version` | Show only the BDR version related keys and values. This includes the full version of the BDR extension, the Postgres version and flavor it is running against, and the BDRPG and BDR plugin API versions. |
 | `--debug` | Show only the BDR debug keys and values, including build information and feature enablement. |
 
 #### Example