Replace 'SYNCHRONOUS_COMMIT' with 'SYNCHRONOUS COMMIT' in 5.6 docs (#…

…6172)

* Added bdr_config - reformatted node state table.

Signed-off-by: Dj Walker-Morgan <[email protected]>

* Known issues as of 30Oct update (#6195)

* Known issues as of 30Oct update

Signed-off-by: Dj Walker-Morgan <[email protected]>

* small changes.

---------

Signed-off-by: Dj Walker-Morgan <[email protected]>
Co-authored-by: Josh Earlenbaugh <[email protected]>

* Update known issues for BFILE

Signed-off-by: Dj Walker-Morgan <[email protected]>

* replaced in commit-scope-rules.mdx

* Replaced in degrading.mdx.

* Replaced in synchronous commit page.

* Replaced in references.

* Resolving conflict

* Update product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx

Co-authored-by: Dj Walker-Morgan <[email protected]>

---------

Signed-off-by: Dj Walker-Morgan <[email protected]>
Co-authored-by: Dj Walker-Morgan <[email protected]>
Co-authored-by: Dj Walker-Morgan <[email protected]>

product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx

@@ -61,11 +61,11 @@ If you're familiar with PostgreSQL's `synchronous_standby_names` feature, be awa
 
 Currently, there are four commit scope kinds. The following is a summary, with links to more details.
 
-### `SYNCHRONOUS_COMMIT`
+### `SYNCHRONOUS COMMIT`
 
-Synchronous Commit is a commit scope option that's designed to behave like the native Postgres `synchronous_commit` option, but is usable from within the commit scope environment. Unlike `GROUP COMMIT`, it's a synchronous non-two-phase commit operation. Like `GROUP COMMIT`, it supports an optional `DEGRADE ON` clause. The commit scope group that comes before this option controls the groups and confirmation requirements the `SYNCHRONOUS_COMMIT` uses.
+Synchronous Commit is a commit scope option that's designed to behave like the native Postgres `synchronous_commit` option, but is usable from within the commit scope environment. Unlike `GROUP COMMIT`, it's a synchronous non-two-phase commit operation. Like `GROUP COMMIT`, it supports an optional `DEGRADE ON` clause. The commit scope group that comes before this option controls the groups and confirmation requirements the `SYNCHRONOUS COMMIT` uses.
 
-For more details, see [`SYNCHRONOUS_COMMIT`](synchronous_commit).
+For more details, see [`SYNCHRONOUS COMMIT`](synchronous_commit).
 
 ### `GROUP COMMIT`
 
@@ -94,7 +94,7 @@ For more details, see [`LAG CONTROL`](lag-control).
 Commit scope rules are composed of one or more operations that work in combination. Use an AND to form a single rule. For example:
 
 ```
-MAJORITY (Region_A) SYNCHRONOUS_COMMIT AND ANY 1 (Region_A) LAG CONTROL (MAX_LAG_SIZE = '50MB')
+MAJORITY (Region_A) SYNCHRONOUS COMMIT AND ANY 1 (Region_A) LAG CONTROL (MAX_LAG_SIZE = '50MB')
 ```
 
 The first operation sets up a synchronous commit against a majority of `Region_A`. The second operation adds lag control that starts pushing the commit delay up when any one of the nodes in `Region_A` has more than 50MB of lag. This combination of operations allows the lag control to operate when any node is lagging.

product_docs/docs/pgd/5.6/commit-scopes/degrading.mdx

@@ -4,7 +4,7 @@ navTitle: Degrading
 deepToC: true
 ---
 
-`SYNCHRONOUS_COMMIT`, `GROUP COMMIT`, and `CAMO` each have the optional capability of degrading the requirements for transactions when particular performance thresholds are crossed.
+`SYNCHRONOUS COMMIT`, `GROUP COMMIT`, and `CAMO` each have the optional capability of degrading the requirements for transactions when particular performance thresholds are crossed.
 
 When a node is applying a transaction and that transaction times out, it can be useful to trigger a process of degrading the requirements of the transaction to be completed, rather than just rolling back. 
 
@@ -24,31 +24,31 @@ This mechanism alone is insufficient for the intended behavior, as this alone wo
 
 To avoid this, the PGD manager process also periodically (every 5s) checks the connectivity and apply rate (the one in [bdr.node_replication_rates](/pgd/latest/reference/catalogs-visible/#bdrnode_replication_rates)) and if there are commit scopes that would degrade at that point based on the current state of replication, they will be automatically degraded—such that any transaction using that commit scope when processing after that uses the degraded rule instead of waiting for timeout—until the manager process detects that replication is moving swiftly enough again.
 
-## SYNCHRONOUS_COMMIT and GROUP COMMIT 
+## SYNCHRONOUS COMMIT and GROUP COMMIT 
 
-Both `SYNCHRONOUS_COMMIT` and `GROUP COMMIT` have `timeout` and `require_write_lead` parameters, with defaults of `0` and `false` respectively. You should probably always set the `timeout`, as the default of `0` causes an instant degrade. You can also require that the write leader be the originator of the transaction in order to switch to degraded mode (again, default is `false`).
+Both `SYNCHRONOUS COMMIT` and `GROUP COMMIT` have `timeout` and `require_write_lead` parameters, with defaults of `0` and `false` respectively. You should probably always set the `timeout`, as the default of `0` causes an instant degrade. You can also require that the write leader be the originator of the transaction in order to switch to degraded mode (again, default is `false`).
 
-Both `SYNCHRONOUS_COMMIT` and `GROUP COMMIT` also have options regarding which rule you can degrade to—which depends on which rule you are degrading from.
+Both `SYNCHRONOUS COMMIT` and `GROUP COMMIT` also have options regarding which rule you can degrade to—which depends on which rule you are degrading from.
 
 First of all, you can degrade to asynchronous operation:
 
 ```sql
-ALL (left_dc) SYNCHRONOUS_COMMIT DEGRADE ON (timeout=20s) TO ASYNC
+ALL (left_dc) SYNCHRONOUS COMMIT DEGRADE ON (timeout=20s) TO ASYNC
 ```
 
 You can also degrade to a less restrictive commit group with the same commit scope kind (again as long as the kind is either `SYNCHRONOUS_COMMIT` or `GROUP COMMIT`). For instance, you can degrade as follows:
 
 ```sql
-ALL (left_dc) SYNCHRONOUS_COMMIT DEGRADE ON (timeout=20s) TO MAJORITY (left_dc) SYNCHRONOUS_COMMIT
+ALL (left_dc) SYNCHRONOUS COMMIT DEGRADE ON (timeout=20s) TO MAJORITY (left_dc) SYNCHRONOUS COMMIT
 ```
 
 or as follows:
 
 ```sql
-ANY 3 (left_dc) SYNCHRONOUS_COMMIT DEGRADE ON (timeout=20s) TO ANY 2 (left_dc) SYNCHRONOUS_COMMIT
+ANY 3 (left_dc) SYNCHRONOUS COMMIT DEGRADE ON (timeout=20s) TO ANY 2 (left_dc) SYNCHRONOUS COMMIT
 ```
 
-But you cannot degrade from `SYNCHRONOUS_COMMIT` to `GROUP COMMIT` or the other way around.
+But you cannot degrade from `SYNCHRONOUS COMMIT` to `GROUP COMMIT` or the other way around.
 
 ## CAMO 
 

product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx

@@ -3,31 +3,30 @@ title: Synchronous Commit
 deepToC: true
 ---
 
-Commit scope kind: `SYNCHRONOUS_COMMIT`
-alias: `SYNCHRONOUS COMMIT`
+Commit scope kind: `SYNCHRONOUS COMMIT`
 
 ## Overview
 
-PGD's `SYNCHRONOUS_COMMIT` is a commit scope kind that works in a way that's more like PostgreSQL's [`synchronous_commit`](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT) option in its underlying operation. Unlike the PostgreSQL option, though, it's configured as a commit scope and is easier to configure and interact with in PGD. 
+PGD's `SYNCHRONOUS COMMIT` is a commit scope kind that works in a way that's more like PostgreSQL's [`synchronous_commit`](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT) option in its underlying operation. Unlike the PostgreSQL option, though, it's configured as a commit scope and is easier to configure and interact with in PGD. 
 
-Unlike other commit scope kinds, such as `GROUP COMMIT` and `CAMO`, the transactions in a `SYNCHRONOUS_COMMIT` operation aren't transformed into a two-phase commit (2PC) transaction. They work more like a Postgres `synchronous_commit`.
+Unlike other commit scope kinds, such as `GROUP COMMIT` and `CAMO`, the transactions in a `SYNCHRONOUS COMMIT` operation aren't transformed into a two-phase commit (2PC) transaction. They work more like a Postgres `synchronous_commit`.
 
 ## Example
 
-In this example, when this commit scope is in use, any node in the `left_dc` group uses `SYNCHRONOUS_COMMIT` to replicate changes to the other nodes in the `left_dc` group. It looks for a majority of nodes in the `left_dc` group to confirm that they committed the transaction.
+In this example, when this commit scope is in use, any node in the `left_dc` group uses `SYNCHRONOUS COMMIT` to replicate changes to the other nodes in the `left_dc` group. It looks for a majority of nodes in the `left_dc` group to confirm that they committed the transaction.
 
 ```
 SELECT bdr.add_commit_scope(
     commit_scope_name := 'example_sc_scope',
     origin_node_group := 'left_dc',
-    rule := 'MAJORITY (left_dc) SYNCHRONOUS_COMMIT',
+    rule := 'MAJORITY (left_dc) SYNCHRONOUS COMMIT',
     wait_for_ready := true
 );
 ```
 
 ## Configuration
 
-`SYNCHRONOUS_COMMIT` supports the optional `DEGRADE ON` clause. See the [`SYNCHRONOUS_COMMIT`](/pgd/latest/reference/commit-scopes/#synchronous_commit) commit scope reference for specific configuration parameters or see [this section](degrading) regarding Degrade on options.
+`SYNCHRONOUS COMMIT` supports the optional `DEGRADE ON` clause. See the [`SYNCHRONOUS COMMIT`](/pgd/latest/reference/commit-scopes/#synchronous_commit) commit scope reference for specific configuration parameters or see [this section](degrading) regarding Degrade on options.
 
 ## Confirmation
 
@@ -40,4 +39,7 @@ SELECT bdr.add_commit_scope(
 
 ## Details
 
-Currently `SYNCHRONOUS_COMMIT` doesn't use the confirmation levels of the commit scope rule syntax.
+Currently `SYNCHRONOUS COMMIT` doesn't use the confirmation levels of the commit scope rule syntax.
+
+In commit scope rules, the original keyword `SYNCHRONOUS_COMMIT` is now aliased to `SYNCHRONOUS COMMIT`. The use of a space instead of an underscore helps distinguish it from Postgres's native `SYNCHRONOUS_COMMIT`.
+

product_docs/docs/pgd/5.6/reference/commit-scopes.mdx

@@ -42,7 +42,7 @@ commit_scope_kind:
 { GROUP COMMIT [ ( group_commit_parameter = value [, ... ] ) ] [ ABORT ON ( abort_on_parameter = value ) ] [ DEGRADE ON (degrade_on_parameter = value [, ... ] ) TO commit_scope_degrade_operation ]
   | CAMO [ DEGRADE ON ( degrade_on_parameter = value [, ... ] ) TO ASYNC ]
   | LAG CONTROL [ ( lag_control_parameter = value [, ... ] ) ] 
-  | SYNCHRONOUS_COMMIT [ DEGRADE ON (degrade_on_parameter = value ) TO commit_scope_degrade_operation ] }
+  | SYNCHRONOUS COMMIT [ DEGRADE ON (degrade_on_parameter = value ) TO commit_scope_degrade_operation ] }
 
 commit_scope_degrade_operation:
    commit_scope_group confirmation_level commit_scope_kind
@@ -55,12 +55,12 @@ Where `node_group` is the name of a PGD data node group.
 
 The `commit_scope_degrade_operation` is either the same commit scope kind with a less restrictive commit scope group as the overall rule being defined, or is asynchronous (`ASYNC`). 
 
-For instance, [you can degrade](/pgd/latest/commit-scopes/degrading/) from an `ALL SYNCHRONOUS_COMMIT` to a `MAJORITY SYNCHRONOUS_COMMIT` or a `MAJORITY SYNCHRONOUS_COMMIT` to an `ANY 3 SYNCHRONOUS_COMMIT` or even an `ANY 3 SYNCHRONOUS_COMMIT` to an `ANY 2 SYNCHRONOUS_COMMIT`. You can also degrade from `SYNCRHONOUS_COMMIT` to `ASYNC`. However, you cannot degrade from `SYNCHRONOUS_COMMIT` to `GROUP_COMMIT` or the other way around, regardless of the commit scope groups involved. 
+For instance, [you can degrade](/pgd/latest/commit-scopes/degrading/) from an `ALL SYNCHRONOUS COMMIT` to a `MAJORITY SYNCHRONOUS COMMIT` or a `MAJORITY SYNCHRONOUS COMMIT` to an `ANY 3 SYNCHRONOUS COMMIT` or even an `ANY 3 SYNCHRONOUS COMMIT` to an `ANY 2 SYNCHRONOUS COMMIT`. You can also degrade from `SYNCHRONOUS COMMIT` to `ASYNC`. However, you cannot degrade from `SYNCHRONOUS COMMIT` to `GROUP COMMIT` or the other way around, regardless of the commit scope groups involved. 
 
 It is also possible to combine rules using `AND`, each with their own degradation clause:
 
 ```
-ALL ORIGIN_GROUP SYNCHRONOUS_COMMIT DEGRADE ON (timeout = 10s) TO MAJORITY ORIGIN_GROUP SYNCHRONOUS COMMIT AND ANY 1 NOT ORIGIN_GROUP SYNCHRONOUS_COMMIT DEGRADE ON (timeout = 20s) TO ASYNC
+ALL ORIGIN_GROUP SYNCHRONOUS COMMIT DEGRADE ON (timeout = 10s) TO MAJORITY ORIGIN_GROUP SYNCHRONOUS COMMIT AND ANY 1 NOT ORIGIN_GROUP SYNCHRONOUS COMMIT DEGRADE ON (timeout = 20s) TO ASYNC
 ```
 
 ## Commit scope targets
@@ -73,7 +73,7 @@ Instead of targeting a specific group, you can also use `ORIGIN_GROUP`, which dy
 SELECT bdr.add_commit_scope(
     commit_scope_name := 'example_scope',
     origin_node_group := 'top_level_group',
-    rule := 'MAJORITY ORIGIN_GROUP SYNCHRONOUS_COMMIT',
+    rule := 'MAJORITY ORIGIN_GROUP SYNCHRONOUS COMMIT',
     wait_for_ready := true
 );
 ```
@@ -155,10 +155,10 @@ More details of the commit scope kinds and details of their parameters:
 Specify Boolean, enum, int, and interval values using the [Postgres GUC parameter value conventions](https://www.postgresql.org/docs/current/config-setting.html#CONFIG-SETTING-NAMES-VALUES). 
 !!!
 
-## SYNCHRONOUS_COMMIT
+## SYNCHRONOUS COMMIT
 
 ```
-SYNCHRONOUS_COMMIT [ DEGRADE ON (degrade_on_parameter = value ) TO commit_scope_degrade_operation ]
+SYNCHRONOUS COMMIT [ DEGRADE ON (degrade_on_parameter = value ) TO commit_scope_degrade_operation ]
 ```
 
 ### DEGRADE ON parameters
@@ -172,11 +172,11 @@ These set the conditions on which the commit scope rule will degrade to a less r
 
 ### commit_scope_degrade_operation
 
-The `commit_scope_degrade_operation` must be `SYNCHRONOUS_COMMIT` with a less restrictive commit scope group—or must be asynchronous (`ASYNC`).
+The `commit_scope_degrade_operation` must be `SYNCHRONOUS COMMIT` with a less restrictive commit scope group—or must be asynchronous (`ASYNC`).
 
 ## GROUP COMMIT
 
-Allows commits to be confirmed by a consensus of nodes, controls conflict resolution settings, and, like [`SYNCHRONOUS_COMMIT`](#synchronous_commit), has optional rule-degredation parameters.
+Allows commits to be confirmed by a consensus of nodes, controls conflict resolution settings, and, like [`SYNCHRONOUS COMMIT`](#synchronous_commit), has optional rule-degredation parameters.
 
 ```
 GROUP COMMIT [ ( group_commit_parameter = value [, ...] ) ] [ ABORT ON ( abort_on_parameter = value ) ] [ DEGRADE ON (degrade_on_parameter = value ) TO commit_scope_degrade_operation ]