Merge pull request #6210 from EnterpriseDB/DOCS-1076-documenting-pgd-5-6-1-5-next

DOCS-1076 - Documenting PGD 5.6.1

Author: djw-m

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.create_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.create_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/compatibility.mdx

@@ -1,20 +1,55 @@
 ---
-title: PGD compatibility by PostgreSQL version
+title: PGD compatibility
 navTitle: Compatibility
 description: Compatibility of EDB Postgres Distributed with different versions of PostgreSQL
+deepToC: true
 ---
 
-The following table shows the major versions of PostgreSQL and each version of EDB Postgres Distributed (PGD) they are compatible with.
+## PGD compatibility with PostgreSQL versions
 
-| Postgres<br/>Version | PGD 5        | PGD 4        | PGD 3.7          | PGD 3.6          |
-|----------------------|--------------|--------------|------------------|------------------|
-| 16                   | [5.3+](/pgd/latest/) |              |                  |                  |
-| 15                   | [5](/pgd/latest/) |              |                  |                  |
-| 14                   | [5](/pgd/latest/) | [4](/pgd/4/) |                  |                  |
-| 13                   | [5](/pgd/latest/) | [4](/pgd/4/) | [3.7](/pgd/3.7/) |                  |
-| 12                   | [5](/pgd/latest/) | [4](/pgd/4/) | [3.7](/pgd/3.7/) |                  |
-| 11                   |              |              | [3.7](/pgd/3.7/) | [3.6](/pgd/3.6/) |
-| 10                   |              |              |                  | [3.6](/pgd/3.6/) |
+The following table shows the major versions of PostgreSQL and each version of EDB Postgres Distributed (PGD) they are compatible with. 
 
+| Postgres Version | PGD 5                  | PGD 4        |
+|----------------------|------------------------|--------------|
+| 17                   | [5.6.1+](/pgd/latest/) |              |
+| 16                   | [5.3+](/pgd/latest/)    |              |
+| 15                   | [5](/pgd/latest/)      |              |
+| 14                   | [5](/pgd/latest/)      | [4](/pgd/4/) |
+| 13                   | [5](/pgd/latest/)      | [4](/pgd/4/) |
+| 12                   | [5](/pgd/latest/)      | [4](/pgd/4/) |
 
 
+
+## PGD compatibility with operating systems and architectures
+
+The following tables show the versions of EDB Postgres Distributed and their compatibility with various operating systems and architectures.
+
+### Linux x86_64 (amd64)
+
+| Operating System                   | PGD 5 | PGD 4 |
+|------------------------------------|-------|-------|
+| RHEL 8/9                           | Yes   | Yes   |
+| Oracle Linux 8/9                   | Yes   | Yes   |
+| Rocky Linux/AlmaLinux              | Yes   | Yes   |
+| SUSE Linux Enterprise Server 15SP5 | Yes   | Yes   |
+| Ubuntu 20.04/22.04/24.04           | Yes   | Yes   |
+| Debian 11/12                       | Yes   | Yes   |
+
+### Linux ppc64le
+
+| Operating System | PGD 5 | PGD 4 |
+|------------------|-------|-------|
+| RHEL 8/9         | Yes   | No    |
+
+
+### Linux arm64/aarch64
+
+| Operating System | PGD 5&sup1; | PGD 4 |
+|------------------|-------|-------|
+| Debian 12        | Yes   | No    |
+| RHEL 9&sup2;         | Yes   | No    |
+
+&sup1; From PGD 5.6.1 onwards
+
+&sup2; Postgres 12 is not supported on RHEL 9 on arm64/aarch64
+

product_docs/docs/pgd/5.6/conflict-management/conflicts/02_types_of_conflict.mdx

@@ -31,16 +31,22 @@ To resolve this conflict type, you can also use column-level conflict resolution
 
 You can effectively eliminate this type of conflict by using [global sequences](../../sequences/#pgd-global-sequences).
 
-### INSERT operations that violate multiple UNIQUE constraints
+### 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`. If a new row violates more than one `UNIQUE` constraint and that results in a conflict against more than one other row, then applying the replication change produces a `multiple_unique_conflicts` conflict.
+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. 
 
-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. The deletion tries to preserve the row with the correct `PRIMARY KEY` and delete the others.
+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 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. 
+The deletion tries to preserve the row with the correct `PRIMARY KEY` and delete the others.
 
 !!! Warning
-    In case of multiple rows conflicting this way, if the result of conflict resolution is to proceed with the insert operation, some of the data is always deleted.
+In case of multiple rows conflicting this way, if the result of conflict resolution is to proceed with the insert operation, some of the data is always deleted.
+!!!
 
-You can also define a different behavior using a conflict trigger.
+You can also define a different behavior using a [conflict trigger](/pgd/latest/striggers/#conflict-triggers).
 
 ### UPDATE/UPDATE conflicts
 
@@ -165,9 +171,9 @@ changes, make those changes using Eager Replication.
 !!! Warning
     In case the conflict resolution of `update_pkey_exists` conflict results in update, one of the rows is always deleted.
 
-### UPDATE operations that violate multiple UNIQUE constraints
+### UPDATE operations that violate UNIQUE or EXCLUDE constraints
 
-Like [INSERT operations that violate multiple UNIQUE constraints](#insert-operations-that-violate-multiple-unique-constraints), when an incoming `UPDATE` violates more than one `UNIQUE` index (or the `PRIMARY KEY`), PGD raises a `multiple_unique_conflicts` conflict.
+Like [INSERT operations that violate multiple UNIQUE/EXLUDE constraints](#insert-operations-that-violate-unique-or-exclude-constraints), when an incoming `UPDATE` violates more than one `UNIQUE`/`EXCLUDE index (including the `PRIMARY KEY`) or violates a single `EXCLUDE` index such that more than one row is in conflict, PGD raises a `multiple_unique_conflicts` conflict.
 
 PGD supports deferred unique constraints. If a transaction can commit on the source, then it applies cleanly on target, unless it sees conflicts. However, you can't use a deferred primary key as a REPLICA IDENTITY, so the use cases are already limited by that and the warning about using multiple unique constraints.
 

product_docs/docs/pgd/5.6/ddl/ddl-command-handling.mdx

@@ -118,7 +118,7 @@ under the following table.
 | CREATE STATISTICS                | Y                                             | Y                                          | DDL                                              |
 | CREATE SUBSCRIPTION              | Y                                             | Y                                          | DDL                                              |
 | CREATE SYNONYM                   | Y                                             | Y                                          | DDL                                              |
-| CREATE TABLE                     | [Details](#bdr_ddl_allowed_CreateStmt)        | Y                                          | DDL                                              |
+| CREATE TABLE                     | Y                                             | Y                                          | DDL                                              |
 | CREATE TABLE AS                  | [Details](#bdr_ddl_allowed_CreateTableAsStmt) | Y                                          | DDL                                              |
 | CREATE TABLESPACE                | Y                                             | N                                          | N                                                |
 | CREATE TEXT SEARCH CONFIGURATION | Y                                             | Y                                          | DDL                                              |
@@ -253,10 +253,12 @@ Some variants of `ALTER TABLE` currently aren't allowed on a PGD node:
 -   `ADD COLUMN ... DEFAULT (non-immutable expression)` — 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.
--   `ALTER TABLE ... SET WITH[OUT] OIDS` — Isn't supported for the same reasons
-    as in `CREATE TABLE`.
+    This can be overriden using `bdr.permit_unsafe_commands` if user is sure the command is
+    safe.
 -   `ALTER COLUMN ... SET STORAGE external` — 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
+    safe.
 -   `RENAME` — Can't rename an Autopartitioned table.
 -   `SET SCHEMA` — Can't set the schema of an Autopartitioned table.
 -   `ALTER COLUMN ... TYPE` — Changing a column's type isn't supported if the
@@ -272,6 +274,8 @@ Some variants of `ALTER TABLE` currently aren't allowed on a PGD node:
     AccessExclusiveLock for extended periods on larger tables, so such commands
     are likely to be infeasible on highly available databases in any case.
     See [Changing a column's type](ddl-workarounds/#changing-a-columns-type) for a suggested workaround.
+    This can be overriden using `bdr.permit_unsafe_commands` if user is sure the command is
+    safe.
 -   `ALTER TABLE ... ADD FOREIGN KEY` — Isn't supported if current user doesn't have
     permission to read the referenced table or if the referenced table
     has RLS restrictions enabled that the current user can't bypass.
@@ -500,13 +504,6 @@ break the replication due to the `writer` worker throwing the error: `cannot cha
 Generally `CREATE SEQUENCE` is supported, but when using global
 sequences, some options have no effect.
 
-<div id='bdr_ddl_allowed_CreateStmt'></div>
-
-### CREATE TABLE
-
-Generally `CREATE TABLE` is supported, but `CREATE TABLE WITH OIDS` isn't
-allowed on a PGD node.
-
 <div id='bdr_ddl_allowed_CreateTableAsStmt'></div>
 
 ### CREATE TABLE AS and SELECT INTO

product_docs/docs/pgd/5.6/decoding_worker.mdx

@@ -1,5 +1,6 @@
 ---
 title: Decoding worker
+description: Decoding worker in PGD reduces CPU overhead and increases replication throughput by enabling a optimized decoding worker process.
 ---
 
 PGD provides an option to enable a decoding worker process that performs